Lot_1_MTR_transport_Funktsionalnye_trebovaniya
реклама
1 ООО «Газпром бурение» УТВЕРЖДАЮ Заместитель Генерального директора по обеспечению и комплектации ООО «Газпром бурение» ___________________ М.В. Шумилишский «__»______________ 2015 «Корпоративная автоматизированная система управления бизнеспроцессами Материально-технического и транспортного обеспечения в ООО «Газпром бурение» Функциональные требования Действует с 15.09.2015 Версия 1 введен впервые Москва 2015 2 ОГЛАВЛЕНИЕ 1. ОБЩИЕ СВЕДЕНИЯ ..................................................................................................................................................... 4 1.1. НАИМЕНОВАНИЕ ПРОЕКТА ....................................................................................................................................................... 4 1.2. ФУНКЦИОНАЛЬНЫЙ ЗАКАЗЧИК ПРОЕКТА .................................................................................................................................... 4 1.3. ОСНОВАНИЯ ДЛЯ РАЗРАБОТКИ .................................................................................................................................................. 4 1.4. СРОКИ РЕАЛИЗАЦИИ ПРОЕКТА .................................................................................................................................................. 4 2. НАЗНАЧЕНИЕ СИСТЕМЫ ............................................................................................................................................ 4 2.1. НАЗНАЧЕНИЕ .......................................................................................................................................................................... 4 2.2. ОРГАНИЗАЦИОННЫЙ ОБЪЕМ ПРОЕКТА. ...................................................................................................................................... 4 3. ЦЕЛИ И ЗАДАЧИ СОЗДАНИЯ АСУ МТО.TMS .............................................................................................................. 5 3.1. ЦЕЛЬ ПРОЕКТА ....................................................................................................................................................................... 5 3.2. ЗАДАЧИ ПРОЕКТА ................................................................................................................................................................... 5 3.3. ФУНКЦИОНАЛЬНЫЙ ОБЪЕМ ПРОЕКТА ........................................................................................................................................ 5 3.3.1. Группа процессов «Планирование» ................................................................................................................... 6 3.3.2. Группа процессов «Обеспечение потребностей» .......................................................................................... 6 3.3.3. Группа процессов «Управление запасами» ...................................................................................................... 7 3.3.4. Группа процессов «Управление транспортом» ............................................................................................. 7 4. ТРЕБОВАНИЯ К КОРПОРАТИВНОЙ АВТОМАТИЗИРОВАННОЙ СИСТЕМЕ УПРАВЛЕНИЯ БИЗНЕС-ПРОЦЕССАМИ ТЕХНИЧЕСКОГО ОБСЛУЖИВАНИЯ И РЕМОНТА ОБОРУДОВАНИЯ (АСУ МТО.TMS) .................................................. 7 4.1. ТРЕБОВАНИЯ К СИСТЕМЕ АСУ МТО.TMS В ЦЕЛОМ ..................................................................................................................... 7 4.1.1. Требования к численности и квалификации персонала системы и режиму его работы: ........................ 7 4.1.2. Требования к архитектуре системы АСУ MTO.TMS ...................................................................................... 8 4.1.3. Требования к конфигурации рабочих станций ............................................................................................... 9 4.1.4. Требования к надежности: ............................................................................................................................. 10 4.1.5. Требования к программно-аппаратному комплексу системы. .................................................................. 10 4.1.6. Требования к серверу мобильных приложений ............................................................................................. 11 4.1.7. Виртуализация ................................................................................................................................................. 11 4.1.8. Требования к серверной подсети ................................................................................................................... 11 4.1.9. Требования к защите информации от несанкционированного доступа ................................................. 12 4.1.10. Требования по сохранности информации при авариях ......................................................................... 12 4.1.11. Требования к защите от влияния внешних воздействий .................................................................... 13 4.1.12. Требования по стандартизации и унификации ..................................................................................... 13 4.1.13. Дополнительные требования ................................................................................................................. 13 4.2. ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ К БЛОКУ «УПРАВЛЕНИЕ ЗАКУПКАМИ». ...................................................................................... 14 4.2.1. Ценообразование и начало планирования в системе. ................................................................................. 14 4.2.2. Определение параметров планирования потребностей необходимо осуществлять с использованием справочника «Заявочная компания». ................................................................................. 16 4.2.3. Формирование лимитов .................................................................................................................................. 17 4.2.4. Ввод и согласование потребностей. ............................................................................................................. 17 4.2.5. Корректировка потребности. ....................................................................................................................... 22 4.2.6. Согласование потребности. ........................................................................................................................... 24 4.2.7. Обеспечение потребностей (Часть процесса управление запасами). ...................................................... 26 4.2.8. Выбор поставщика номенклатуры ............................................................................................................... 30 4.2.9. Выполнение закупки. ........................................................................................................................................ 45 4.3. ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ К БЛОКУ «УПРАВЛЕНИЕ ЗАПАСАМИ»......................................................................................... 49 4.3.1. Регистрация поступления товаров и услуг.................................................................................................. 50 4.3.2. Распределение ТМЦ по потребностям ......................................................................................................... 51 4.3.3. Перемещение ТМЦ на основании потребности ........................................................................................... 52 4.3.4. Формирование ТТН. .......................................................................................................................................... 54 4.3.5. Списание ТМЦ. ................................................................................................................................................... 55 4.3.6. Инвентаризация ТМЦ на складах. .................................................................................................................. 56 4.3.7. Учет аналогов в АСУ МТО ................................................................................................................................ 58 4.3.8. Категоризация запасов ................................................................................................................................... 60 4.3.9. Учет и выдача Спецодежды и СИЗ .................................................................................................................. 61 4.3.10. Операции с основными средствами. ....................................................................................................... 62 4.4. ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ К БЛОКУ «УПРАВЛЕНИЕ ТРАНСПОРТОМ». .................................................................................. 62 3 4.4.1. Основные требования. .................................................................................................................................... 62 4.4.2. Ведение нормативов ....................................................................................................................................... 63 4.4.3. Ведение лимитов.............................................................................................................................................. 64 4.4.4. Планирование потребностей в технике ...................................................................................................... 68 4.4.5. История работы с подрядчиком .................................................................................................................... 75 4.4.6. Формирование заявки подрядчику .................................................................................................................. 76 4.4.7. Получение и обработка информации при помощи БСМТС .......................................................................... 84 4.4.8. Фиксирование фактического использования техники ................................................................................ 87 4.4.9. Согласование с подрядчиком объема выполненных работ ......................................................................... 95 4.4.10. Учет ГСМ ..................................................................................................................................................... 97 4.4.11. Фиксирование условий договоров............................................................................................................. 99 4.5. ТРЕБОВАНИЯ К БЛОКУ «УПРАВЛЕНИЕ УСЛУГАМИ» ...................................................................................................................108 4.5.1. Общее описание процесса учета услуг ........................................................................................................108 4.5.2. Фиксирование услуг буровым мастером .....................................................................................................109 4.6. ОБЩИЕ ТРЕБОВАНИЯ К БЛОКАМ СИСТЕМЫ АСУ МТО.TMS .....................................................................................................111 4.6.1. Формирование плана оплат. ........................................................................................................................111 4.6.2. Бюджетный контроль. .................................................................................................................................112 4.6.3. Управление эффективностью деятельности поставщиков. .................................................................112 4.6.4. Мобильный клиент. .......................................................................................................................................113 4.6.5. Рабочее место для буровых мастеров. .......................................................................................................113 4.6.6. Работа системы через WEB..........................................................................................................................114 4.6.7. Обязанности исполнителя. ..........................................................................................................................114 4.6.8. Сопровождение системы. .............................................................................................................................114 5. ТРЕБОВАНИЯ К СОСТАВУ И СОДЕРЖАНИЮ РАБОТ ПО ПРИЕМКЕ СИСТЕМЫ И ПОДГОТОВКЕ К ВВОДУ АСУ MTO.TMS В ДЕЙСТВИЕ ........................................................................................................................................... 114 5.1. ПЕРЕЧЕНЬ ПОДГОТОВИТЕЛЬНЫХ МЕРОПРИЯТИЙ ......................................................................................................................114 5.2. ОБЩИЕ ТРЕБОВАНИЯ ...........................................................................................................................................................115 5.3. ПОРЯДОК ПРИЁМКИ РАБОТ...................................................................................................................................................115 5.3.1. Приёмка системы и передача в промышленную эксплуатацию ..............................................................119 6. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ ............................................................................................................... 121 7. ТЕРМИНЫ, ОПРЕДЕЛЕНИЯ, СОКРАЩЕНИЯ ........................................................................................................... 123 ПРИЛОЖЕНИЕ А ОРИЕНТИРОВОЧНЫЙ КАЛЕНДАРНЫЙ ПЛАН РАЗРАБОТКИ И ТИРАЖИРОВАНИЯ ............ 124 8. УПРАВЛЕНИЕ ДОКУМЕНТОМ ................................................................................................................................ 125 8.1. ЛИСТ СОГЛАСОВАНИЙ..........................................................................................................................................................125 8.2. ЛИСТ РЕГИСТРАЦИИ ИЗМЕНЕНИЙ ..........................................................................................................................................126 4 1. ОБЩИЕ СВЕДЕНИЯ 1.1. Наименование Проекта Настоящее Техническое задание разработано для реализации программы внедрения Корпоративной автоматизированной системы управления бизнеспроцессами материально-технического и транспортного обеспечения, далее АСУ МТО.TMS 1.2. Функциональный заказчик Проекта Функциональным заказчиком Проекта является ООО «Газпром бурение» Заместитель Генерального директора по обеспечению и комплектации Михаил Викторович Шумилишский. 1.3. Основания для разработки Основанием для разработки является Стратегия развития системы снабжения ООО «Газпром бурение» 1.4. Сроки реализации Проекта Сроки реализации проекта: Разработка системы до января 2016 года; Внедрение и тиражирование февраль-декабрь 2016 года. 2. НАЗНАЧЕНИЕ СИСТЕМЫ 2.1. Назначение Система предназначена для автоматизации процессов закупки МТР, управления запасами, управление транспортом. 2.2. Организационный объем Проекта. Проектом «Корпоративная автоматизированная система управления бизнес-процессами Материально-технического и транспортного обеспечения в ООО «Газпром бурение» охватываются следующие организационные подразделения ООО «Газпром бурение»: № 1 2 3 4 5 6 Наименование организации ООО «Газпром бурение», ЦАУ (Москва) Филиал «Уренгой бурение» Филиал «Ухта бурение» Филиал «Краснодар бурение» Филиал «Оренбург бурение» Филиал «Астрахань бурение» Ориентировочное число пользователей ≈ 15 ≈ 40 ≈ 25 ≈ 25 ≈ 35 ≈ 15 5 № Ориентировочное число пользователей ≈ 150 Наименование организации ИТОГО: 3. ЦЕЛИ И ЗАДАЧИ СОЗДАНИЯ АСУ МТО.TMS 3.1. Цель Проекта a) Ключевая цель проекта – создание инструмента для эффективной системы снабжения. b) Внедрение автоматизированной системы управления для: a. повышения качества планирования потребностей; b. выполнения и контроля процесса закупки; c. эффективное использование запасов; d. повышения качества данных об активах; e. контроль транспорта; f. управление поставщиками МТР и услуг. 3.2. Задачи Проекта a) Обеспечение центрального аппарата управления ООО «Газпром бурение» и всех его региональных филиалов единым инструментом для планирования и управления процессами МТО.TMS с обеспечением прозрачности деятельности; b) Внедрение типовой бизнес-модели МТО.TMS на всех региональных филиалах ООО «Газпром бурение»; c) Обеспечение оперативности и достоверности информации об обеспечении производственных подразделений; d) Обеспечение возможности получение объективной отчетности МТО.TMS; e) Разработку и внедрение единых стандартов и принципов выполнения операций для всех региональных филиалов ООО «Газпром бурение»; f) Предоставление отчетности для принятия управленческих решений для всех уровней руководства. 3.3. Функциональный объем проекта 6 В функциональный объем проекта входят следующие процессы: ввод и согласование потребности; выбор способа обеспечения потребности; проведения квалификационных и тендерных процедур; выполнение закупки; фиксация тарифов и цен; управление транспортом; контроль расхода топлива; выполнение складских операций. Настоящий раздел описывает детализацию выполнения процессов МТО.TMS до уровня функций. 3.3.1. Группа процессов «Планирование» № п.п. Наименование объекта/бизнес-процесса 1 Начало планирования 1.1 Определение параметров планирования 1.2 Формирование лимитов 1.3 Согласование лимитов 2 Ввод и согласование потребности 2.1 Ввод долгосрочных потребностей 2.2 Ввод оперативных потребностей 2.3 Согласование потребностей Примечание: система должна обеспечивать возможность прикреплять к записям в базе данных по техническим местам и единицам оборудования документы как в виде скан-образов, так и в формате того программного продукта, с помощью которого он подготовлен. 3.3.2. Группа процессов «Обеспечение потребностей» № п.п. Наименование объекта/бизнес-процесса 1 Обеспечение потребностей 1.1 Анализ складских запасов 2 Выбор поставщика 2.1 Проведение тендерных процедур 2.2 Проведение квалификации и проверку на «СТОП-Информацию» 2.3 Определение победителя 2.4 Фиксация тарифов и цен 3 Выполнение закупки 3.1 Формирование/корректировка заказов поставщику 7 3.3.3. Группа процессов «Управление запасами» № п.п. 1 2 3 4 5 6 Наименование объекта/бизнес-процесса Регистрация поступления товаров; Распределение ТМЦ по потребностям Перемещение ТМЦ и ОС Оформление ТТН Учет аналогов номенклатуры Категоризация запасов 3.3.4. Группа процессов «Управление транспортом» № п.п. 1 2 3 2.1 2.2 2.3 2.4 3 4 Наименование объекта/бизнес-процесса Формирование заявки на ТС подрядчику; Получение и обработка информации при помощи БСМТС Фиксация выполненных работ: Управление и контроль рейсов Контроль работы ТС Распределение затрат Расчет штрафных снкций Фиксация выполненных работ: Фиксирование условий договора 4. ТРЕБОВАНИЯ К КОРПОРАТИВНОЙ АВТОМАТИЗИРОВАННОЙ СИСТЕМЕ УПРАВЛЕНИЯ БИЗНЕС-ПРОЦЕССАМИ ТЕХНИЧЕСКОГО ОБСЛУЖИВАНИЯ И РЕМОНТА ОБОРУДОВАНИЯ (АСУ МТО.TMS) 4.1. Требования к системе АСУ МТО.TMS в целом АСУ MTO.TMS должна представлять собой целостную завершенную функциональную систему. 4.1.1. Требования к численности и квалификации персонала системы и режиму его работы: Режим работы персонала, занятого работой с АСУ MTO.TMS, должен соответствовать режиму, принятому на предприятиях, в соответствии установленным графиком работы (8-и часовой, 12-часовой, вахтовый) и не должен противоречить местному трудовому законодательству. Для круглосуточного дежурства применять сменный или гибкий (скользящий) график работы. Внедрение системы не должно влечь за собой увеличения численности персонала сверх численности, установленной штатным расписанием. 8 Численность персонала, работающего в системе (пользователей системы), должна быть определена на этапе Реализации, в процессе разработки документации по ролям и полномочиям пользователей. При разработке и внедрении системы следует стремиться к минимизации численности персонала, выполняющего функции в Системе без потери качества результатов работы. Квалификация пользователей системы должна соответствовать функциям и задачам, выполнение которых должно быть описано в инструкциях пользователей Системы. К квалификации пользователей системы не должны предъявляться требования, превышающие обычные минимальные требования к пользователям офисных программных продуктов (MS Word, MS Excel), а также к пользователям средств сотовой связи. Для облегчения работы пользователей в системе АСУ MTO.TMS должно максимально использоваться контекстно-зависимые средства помощи. Т.е. на всех экранных формах в командных панелях должна присутствовать «кнопка помощи», которая вызывает краткую справку о назначении того поля или области экрана, на котором находится указатель мышки (или курсор). Контекстная справка должна содержать примеры, пояснения по вводу данных и ограничения, налагаемые на вводимые данные. Помимо этого, у пользователя системы должна быть возможность быстрого поиска и вызова детальных рабочих инструкций по выполнению, как отдельных функций, так и всего бизнес-процесса в целом. Обращение к этим документам не должно требовать от пользователя выхода из системы, либо длительного «блуждания» по иерархии различных меню. 4.1.2. Требования к архитектуре системы АСУ MTO.TMS 4.1.2.1. Общие требования В целях требований правильного систем пользователей, АСУ толкования MTO.TMS используемое для методики считать, оценки что расчета технических активное количество вычислительных ресурсов продуктивных серверов, берется в соотношении 40% от общего числа неблокированных пользовательских учетных записей. Общее количество 9 пользователей АСУ MTO.TMS в продуктивной системе (с учетом всех филиалов и ЦАУ) ориентировочно – 150 чел. 4.1.3. Требования к конфигурации рабочих станций Конфигурация рабочей станции должна отвечать минимальным системным требованиям к аппаратному обеспечению, предъявляемой клиентской частью АСУ MTO.TMS. Минимальная конфигурация рабочей станции (для клиентской части): Стандартная PC архитектура на базе х86. Процессор с тактовой частотой не ниже 1 ГГц. Не менее 1 Гб оперативной памяти. Наличие 7 Гб свободного пространства на диске C: для установки клиентского ПО. Мышь. Клавиатура. VGA или SVGA видеоадаптер. Цветной ЖК- или ЭЛТ- монитор с поддержкой не менее 256 цветов, разрешением не менее 1024x768 пикселей и диагональю не менее 21". Частота вертикальной регенерации для ЭЛТ мониторов с разрешением 1024x768 пикселей – не менее 75 Гц. Сетевой интерфейс Ethernet 10/100 Мбит/сек для подключения в локальную сеть по месту установки. Наличие источника бесперебойного питания. На всех рабочих станциях пользователей должна быть установлена операционная система семейства MS Windows, поддерживающая технологию терминального доступа через WEB-браузер, и утверждённая ИТ стандартами ООО «Газпром бурение». Автоматизированные рабочие места должны быть объединены в локальную TCP/IP сеть с возможностью выхода в корпоративную сеть передачи данных и подключением к АСУ MTO.TMS. Количество автоматизированных рабочих мест соответствует количеству пользователей АСУ MTO.TMS. Пользователь должен иметь возможность печати документов АСУ MTO.TMS со своего рабочего места. 10 4.1.4. Требования к надежности: Срок эксплуатации и среднее время безотказной работы оборудования системы определяются производителями оборудования. Надежность и отказоустойчивость системы должна обеспечиваться за счёт: a) применения схем избыточного резервирования и дублирования компонентов, технологий кластеризации и балансировки нагрузки; b) автоматического переключения на серверы АСУ MTO.TMS резервной площадки в случае аварии. 4.1.5. Требования к программно-аппаратному комплексу системы. Программно-аппаратный комплекс для функционирования должен включать следующие программные средства: a) Microsoft SQL Server 2008SP1 x64 с Накопительным обновлением (CU) выше CU5 или Microsoft SQL Server 2012 для реализации системы хранения. b) Microsoft Windows Server 2008 R2 Standard или Microsoft Windows Server 2012 – операционная система. Для правильного функционирования Системы, в локальной сети Заказчика должны функционировать и быть доступны: a) Служба Active Directory, так же доступная по протоколу LDAP; b) Служба передачи почтовых сообщений SMTP, принимающая соединения без авторизации; На клиентских компьютерах должны быть установлены Интернет-браузеры: a) Microsoft Internet Explorer 8 и выше; b) Mozilla Firefox; c) Apple Safari; d) Google Chrome. На компьютерах сотрудников, выполняющих работу с документами Microsoft Office и почтовый клиент, должны быть установлены пакеты: a) Microsoft Office 2007 и выше. 11 На компьютерах сотрудников, выполняющих администрирование Системы, должен быть установлен браузер Microsoft Internet Explorer 8 и выше. Техническое обеспечение, используемое для создания Системы:. Роль Процессор Интерфейсный вебсервер 64-bit, four-core, 16..24 GB 72 GB.. Eth 100 Mbit 1 2.5 GHz 200 GB minimum per core Архитектура x64 Сервер приложений Сервер СУБД Память Диски Сетевые Колинтерфейсы во 64-bit, four-core, 8..16 GB 72 GB.. Eth 100 Mbit 1 2.5 GHz 200 GB minimum per core Архитектура x64 (возможно использование существующих в организации экземпляров СУБД, удовлетворяющих требованиям) Клиентские компьютеры 1 GHz or faster 2..4Gb x86/x64 processor with SSE2 instruction set от 20Gb Eth 100Mbit N 4.1.6. Требования к серверу мобильных приложений Кол-во пользователей 250 и меньше 500 Кол-во ядер процессора Объем RAM, ГБ 1 2 8 8 Размер жесткого диска, ГБ 50 50 4.1.7. Виртуализация Интерфейсные веб-сервера и сервер приложений могут быть реализованы в среде виртуализации в виде виртуальных машин. 4.1.8. Требования к серверной подсети 12 Пропускная способность каналов связи между серверами системного ландшафта не должна быть менее 100 Мбит/сек. Рекомендуется использование 1000 Мбит/сек сети. Все серверы должны быть включены в изолированный по трафику сегмент локальной сети. Для повышения общей надежности и безопасности системы, а также с целью упрощения администрирования все серверы должны по возможности размещаться в выделенной сети/подсети TCP/IP. Должна быть обеспечена поддержка дистанционного доступа к серверной подсети для дистанционного администрирования ИСУ. Активное коммутационное оборудование серверной подсети должно резервироваться с возможностью автоматического переключения на резерв в случае отказа основного оборудования. 4.1.9. Требования к защите информации от несанкционированного доступа a) Система должна обеспечивать доступ в систему только для зарегистрированных пользователей, прошедших установленную в Компании процедуру аутентификации. b) На стадии внедрения системы необходимо сформировать ролевую модель для организации управлением доступа пользователей к компонентам системы. За администраторами Корпоративно-сервисного центра должны быть закреплены функции управления локальными серверами и пользователями. c) Для обеспечения корпоративного требований сетевого информационной периметра при безопасности построении сегмента пограничных серверов должны использоваться межсетевые экраны и демилитаризованные зоны Заказчика. d) Для внешнего доступа удалённых и внешних пользователей, а также для организации федеративных отношений с другими организациями, необходимо использовать действующие сертификаты, выпущенный коммерческим центром сертификатов. 4.1.10. Требования по сохранности информации при авариях 13 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) исполнение конкурсных процедур; 14 c) ведение договоров на разработку системы и актирование работ по проекту; d) обеспечение коммуникаций со специалистами и менеджерами Заказчика и смежных организаций; e) предоставление информационных материалов; f) ведение проектного документооборота и согласование документации в установленные сроки. Набор документов и регламент их ведения должны быть отражены в Уставе проекта; g) ведение отчетности по проекту; h) исполнение процедуры закрытия проекта. Процедуры закрытия проекта включают в себя подготовку приказа о вводе в ПЭ, подписание акта ввода в эксплуатацию, выдачу отзыва о работе исполнителя, выпуск пресс-релизов. Перечень документов должен быть отражен в Уставе проекта. На этапе внедрения системы Заказчик предоставляет Исполнителю доступ к АСУ MTO.TMS для настройки системы. 4.2. Функциональные требования к блоку «Управление закупками». 4.2.1. Ценообразование и начало планирования в системе. Предполагается следующий алгоритм расчета и хранения цен: a) Документ «Прайс» (содержит номенклатуру и цену за единицу, имеет срок действия). b) В случае отсутствия прайса, цена по номенклатуре подбирается из заказа поставщику по данной номенклатуре. c) В случае отсутствия «Заказа поставщику» - цена должна подбираться из последнего тендера по данной номенклатуре. d) В случае отсутствия тендера – цена подбирается из ПТУ (цена последнего закупа). Если данная номенклатура является новой или по ней не проводилось никаких действий, должна быть возможность ввода цены вручную документом «Ввод цен» или при вводе потребности 15 В системе Расчет цен с использованием алгоритмов расчета на основании цен, предыдущих периодов, зарегистрированных в Системе должен, предполагать использование операций: Удалить (обнулить); Рассчитать по формуле; Рассчитать по ценам контрагентов; Округлить; Изменить цены на %; Цена из «Прайса»; Цена из последней поставки. Операция «Удалить (обнулить)» позволит удалить (обнулить) цены на выбранную номенклатуру. Операция «Рассчитать по формуле» позволит при указании типа цен, математического действия (плюс или минус) и значения, рассчитать цену, используя формулу. Операция «Рассчитать по ценам контрагентов» позволит рассчитать цены на основании последних закупочных цен, определенного контрагента. Операция «Изменить цены на %» позволит цены, имеющиеся в системе, либо произвольно рассчитанные пользователем, на определенный процент. Операция «Цена из договора» позволит рассчитать последние цены из договоров поставки. Операция «Цена из последней поставки» позволит рассчитать цены на основании последних поставок. В Системе настраиваются типы цен номенклатуры предприятия и типы цен номенклатуры контрагентов: Плановых цен, используемых для планирования и подстановки в документы; Закупочных цен, используемых для анализа последних цен закупки и темпа роста цен; Договорных цен, используемых для определения цен поставки; На основании введенных в Системе типов цен необходимо иметь возможность расчёта других типов цен. Также тип цен должен хранить информацию о валюте цен и методах округления. 16 Для регистрации в Системе плановых цен, с типом цены соответствующему, типу цены параметров планирования (справочник «Заявочная компания»), необходимо использовать документ «Установка цен номенклатуры». Регистрации в Системе цен поступления (тип цены «Закупочная»), может осуществляться типовым механизмом. Для этого необходимо в договорах указывать тип цен контрагентов, а на закладке «Условия закупки», документа «Поступление товаров и услуг», включить флаг «Регистрировать цены закупки». Регистрировать новые цены в Системе необходимо в разрезе филиалов. В работе на любых этапах цены по номенклатуре должны определяться в рамках организации документа. Системе должна иметь возможность регистрировать цены в валюте отличной от управленческой валюты (управленческая валюта - RUB). Планируется использовать отдельный тип цен для каждого календарного года. Например: Плановые цены (Новый год). При создании цены могут рассчитываться на основании плановых цен за прошлый год (Например, может быть создан тип цен = "Плановые цены 2016", данный тип цен будет рассчитываться, как (Плановые цены 2015)*K%), где К – коэффициент инфляции, задается пользователем. 4.2.2. Определение параметров планирования потребностей необходимо осуществлять с использованием справочника «Заявочная компания». В рабочей области «Период заявочной компании», на форме элемента справочника «Заявочные компании», использовать реквизиты «Дата начала» и «Дата окончания», для контроля ввода долгосрочных потребностей в указанный ограниченный период. Данный контроль будет осуществляться на этапе ввода долгосрочных потребностей, посредством обработки «Ввод и согласование потребностей». Система должна хранить значение действующей заявочной компании в регистре «Настройки организаций МТО». Значения будут храниться с периодом действия, равным периоду планирования заявочной компании и в разрезе организаций. В объекты системы данная заявочная компания должна 17 подставляться по умолчанию в качестве значения реквизита «Заявочная компания». Объекты, в которых требуется автоматически заполнять реквизит «Заявочная компания»: Обработка «Ввод и согласование лимитов»; Обработка «Ввод лимитов»; Документ «Обеспечение ЗК»; Документ «Распределение МТР». 4.2.3. Формирование лимитов Формирование лимитов должно осуществляться на основе разрезов планирования, определенных «Заявочной компанией». Для гибкого планирования системой должно быть предусмотрено два варианта списания лимитов: Жесткая связка – ввод и расход лимита по каждому разрезу планирования. Иерархическое планирование (мягкая связка). Планирование по разрезам планирования/списание по группе статей планирования. На примере статей затрат (Таблица 1.): Таблица 1. Группа статей затрат H Наименование затрат статей Масла и смазки Лимит Расход 9 000,00 9 000,00 3 000,00 8 000,00 Статья затрат 2 Масла для ДЭС Масла для буровых насосов 4 000,00 1 000,00 Статья затрат 3 Смазки для механизмов 2 000,00 Статья затрат 1 Из примера видно что лимит по группе статей затрат не превышен. Настройка способа контроля лимита должна настраиваться в справочнике «Заявочная кампания». 4.2.4. Ввод и согласование потребностей. При вводе долгосрочных или оперативных потребностей требуется подтягивать цены автоматически по следующему алгоритма описанного в п.1 «Ценообразование». Если система не найдет цену по заданному алгоритму, инициатору потребности следует обратиться к ответственным сотрудникам, с ролью 18 «Менеджер по управлению закупками», которые зафиксируют цену. Редактирование цен при вводе потребностей не доступно. В случае нахождения на один период двух цен, Система может позволить опционально для каждой организации отдельно указать какую цену подставить: Максимальную; Последнюю. Если цена не определилась, Система не должна позволить отправить на согласование данную потребность с выводом текстового оповещения пользователю. Установка плановой цены по нужной номенклатуре, доступно пользователям с ролью «Менеджер по управлению запасами» или «Организатор планирования. Изменение цен потребностей после отправки на согласование возможно с использованием обработки «Пересчет цен». Данная обработка позволит пересчитать цены в потребностях, находящихся в процессе согласования. После полного согласования потребностей, редактирование цен невозможно. Обработка «Пересчет цен» будет доступна пользователям с ролью «Пересчет цен потребностей». Оповещение участвующих в процедуре согласования не предусмотрено, т.к. изменение цены будет доступно только заинтересованным пользователям. Обработка «Пересчет цен» позволит поддерживать актуальность цен на этапе согласования. В обработке «Ввод и согласование потребностей» при обращении к реквизиту «Вид потребности» проверять следующее: если текущая дата на сервере попадает в период заявочной компании, ограниченный реквизитами «Дата начала» и «Дата окончания», разрешать выбор значения «Долгосрочная». Тем самым мы сможем ограничить ввод долгосрочных потребностей отведенным для этого периодом. Так же пользователь, вводящий потребности, будет оповещен об этом до ввода данных потребностей. 4.2.4.1. Ввод долгосрочных потребностей. 19 Пользователи в рамках долгосрочного планирования определяют объем своих потребностей, с разбивкой на периоды - месяцы. Долгосрочные потребности, в силу своей особенности, формируются с указанием количества или суммы на период (месяц), например Январь 10 шт., февраль 15 шт., и т.д. По умолчанию валюта потребностей определена параметрами планирования и не может редактироваться при формировании потребностей. Введенные, долгосрочные потребности также контролировать на соответствие установленным лимитам. Данный контроль выполнять, если в параметрах «Заявочной компании» установлен реквизит «Контролировать лимиты». 4.2.4.2. Ввод оперативных потребностей. При формировании оперативных (текущих) потребностей на следующий месяц, за основу берутся введенные, согласованные долгосрочные потребности на этот период. В качестве даты потребности устанавливать дату равную началу подпериода. Пример: Если подпериод равен месяцу, тогда дата будет равна первому числу месяца; Если подпериод равен неделе, тогда дата будет равна числу понедельника. Выполнять контроль, при сохранении, ограничивающий дату потребности, а именно «Дата потребности» ≥ текущей даты сервера. Текущая потребности - При формировании оперативных (текущих) потребностей на следующий месяц, за основу необходимо взять план долгосрочных потребностей на этот период. Оперативные потребности могут быть отредактированы. После внесения изменения пользователь отправит оперативные потребности на следующий этап – согласование. Срочная потребности - Для того чтобы повысить важность и критичность своих потребностей пользователю необходима 20 возможность дать своим потребностям, или установить для вновь вводимых потребностей, приоритет срочные. Потребности со срочным приоритетом должны иметь сокращенную процедуру согласования. Данный приоритет будет сигналом, для всех кто впоследствии будет обрабатывать данные потребности. Аварийная потребности - В течение месяца, когда оперативные потребности уже поступили в обработку, у подразделения может появиться аварийная потребность, к немедленному обеспечению. Оперативные потребности должны вводиться с указанием более точной даты. Например: ГСМ 100 л на 15.03.2013, Фильтр 10 шт. на 20.03.2013. Ввод оперативных потребностей с указанием плановой даты необходим для последующего расчета: Плановой даты доставки; Плановой даты исполнения потребности. Алгоритм расчета «Плановой даты исполнения» оперативных потребностей и «Плановой даты доставки» оперативных потребностей. «Плановая дата исполнения» рассчитывается по формуле «Дата утверждения потребности» + «Срок поставки» + «Срок перемещения между складами»; «Плановая дата доставки» рассчитывать по формуле «Дата утверждения потребности» + «Срок поставки». В случае отсутствия договора поставки требуемой номенклатуры, рассчитывать плановые даты с учетом проведения тендерных мероприятий. Таким образом, алгоритм принимает следующий вид: «Плановая дата исполнения» рассчитывается по формуле «Дата утверждения потребности» + «Срок договорных процедур (Календарных дней)» + «Срок поставки» + «Срок перемещения между складами»; 21 «Плановая дата доставки» рассчитывать по формуле «Дата утверждения потребности» + «Срок договорных процедур (Календарных дней)»+ «Срок поставки». Реквизиты «Срок поставки» и «Срок перемещения» между складами хранить в системе в разрезе складов, с возможностью изменения. Данные реквизиты будут храниться как нормативные показатели, без автоматического расчета. Реквизит «Срок договорных процедур (Календарных дней)» хранить в регистре «Настройки организаций МТО» в разрезе организаций, с возможностью изменения. Реквизиты «Плановая дата исполнения» и «Плановая дата доставки» будут представлены пользователям, с ролями «Менеджер по управлению запасами» и «Менеджер по закупкам», при обеспечении потребностей. Также в отчетной форме «Анализ исполнения потребностей» можно будет анализировать реквизиты «Плановая дата исполнения» и «Плановая дата доставки». Ввод потребностей номенклатуры будет возможен как в разрезе самой номенклатуры, так и в разрезе ее характеристик. Возможность ввода характеристик номенклатуры определяется в карточке элемента справочника «Номенклатура», реквизитом «Вести учет по дополнительным характеристикам». Требуется вести учет статей затрат в разрезе Филиалов. Так же Система должна контролировать: Привязку отдельных статей затрат справочник «Статьи затрат» к определённому ЦФО. В добавить реквизит «ЦФО» с возможностью добавления одной статьи затрат к нескольким ЦФО. На форме выбора элементов справочника «Статьи затрат» применять отборы по реквизитам «Организация» и «ЦФО», указанных в настройках пользователя. Связь Номенклатуры и статьи затрат (в случае привязки одной номенклатуры к нескольким статей затрат, на этапе ввода 22 потребности Система должна позволить Пользователю выбрать статью затрат из списка). Т.к. схемы закупки номенклатуры МТР и Основных средств могут отличаться друг от друга, поэтому в системе требуется хранить перечень основных средств в регистре «Основные средства». Регистр содержит аналитики: Организация; Номенклатура; Ответственный. Потребности по данной номенклатуре не должны вести расход лимитов на материалы. Системой должно быть предусмотрено электронное согласование потребностей. Для согласующего должна выводиться полная информация о потребности, включая информацию, о количестве уже заявленном на текущий период и всего. 4.2.5. Корректировка потребности. Процесс корректировки потребностей введенных и сохраненных в систему, но окончательно не согласованных, может производиться непосредственно инициатором потребности. Случаи корректировок потребностей: В процесс ввода – пользователь может корректировать потребности, без каких либо последствий; В процессе согласования – пользователь может корректировать потребности после отзыва с процесса согласования; Согласованных – пользователь может корректировать потребности, только документом «Корректировка потребностей». Процесс корректировки потребностей на этапах, отличных от этапа ввода потребностей, будет производиться с помощью специального документа «Корректировка потребностей». Данный документ предполагается формировать в Системе любым пользователем , с ролью «Инициатор потребности» (должны совпадать Организация и ЦФО). В табличную часть документа «Корректировка 23 потребностей» пользователь должен подбирать только потребности, по которым он является инициатором. При подборе потребностей обязательно ограничивать подбор долгосрочных и оперативных потребностей в рамках одного документа. Также в форме подбора выводить информацию: Номенклатура (доступно к изменению); Номер потребности; Дата потребности (для оперативных потребностей); Период потребности (для долгосрочных потребностей) (доступно к изменению); Количество потребности (доступно к изменению в меньшую сторону); Обеспеченное количество; Текущий статус потребности; Ответственный за обеспечение Статья Затрат (доступно к изменению); Подразделение получатель (доступно к изменению); В процессе обеспечения потребности будут изменять статус, в соответствии с текущим этапом обеспечения. Любой этап процесса обеспечения подразумевает формирование в Системе определенного документа. Корректировка на любом этапе, кроме этапа ввода потребности, должна быть одобрена сотрудником, выполняющим ее обработку, и ответственными руководителями направления. Например, при корректировке на этапе обеспечения, менеджер по закупкам должен подтвердить возможность внесения изменений в потребность. Для данных целей к документу «Корректировка потребностей» должен быть предусмотрен механизм согласования (настройка общая для типа документа, в разрезе Филиала), что позволит оперативно, в электронном виде производить согласование корректировок, а также хранить исторические данные в системе, постоянно доступные для анализа. 24 Корректировка потребности должна быть доступна на любом этапе, до проведения документа «Задание на перемещение». В случае распроводки документов, корректировка может быть осуществлена. 4.2.6. Согласование потребности. Пользователям системы предоставить механизм согласования введенных потребностей, для утверждения затрат по объектам и контролю рамок запланированного лимита. Данный механизм должен обеспечить: Автоматическое построение маршрута согласования (на основании разрезов планирования введенных на этапе ввода потребности); Хранение истории согласования; Анализ процесса согласования на основании исторических данных; Оповещение согласующего; Ограничение в последующей обработке данных, без финального утверждения. АСУ МТО должен самостоятельно выстраивать маршрут согласования в зависимости от параметров данных, например, приоритет или сумма, и определять заинтересованных ответственных сотрудников. Оповещение согласующего производить посредством формирования задач и писем на электронную почту. Анализ процесса согласования на основании исторических данных предусматривает вывод этих данных в отчетную форму. В отчетной форме обязательно наличие информации: ФИО, должность инициатора потребности; ФИО, должность согласующего; Решение согласующего (Утверждено/Отклонено); Комментарии согласующего; Дата и время выполнения согласования (по каждому согласующему). Оповещение согласующего подразумевает оповещений на почту сотрудника, с указанием: рассылку электронных 25 Данных (объекта задачи); Параметров потребностей; Web-ссылка для входа в Систему и открытия задачи на согласование. Ограничение работы с потребностью в последующей обработке подразумевает невозможность обеспечения данных потребностей, если процедура согласования еще не завершена, либо находится в статусе отклонения. Процесс согласования потребностей выстраивается в маршрут, состоящий из ответственных лиц и руководителей организации. Маршрут может строиться двумя типами: Последовательный; Параллельный. В последовательной части маршрута, ответственные пользователи выполняют электронное согласование друг за другом: В случае положительной визы согласующего, данные переходят к следующему согласующему; В случае отрицательной визы согласующего, данные возвращаются к инициатору и после его обработки повторно проходят первоначальный маршрут. При этом обязательно указание причины отклонения. В параллельной части маршрута, ответственные пользователи выполняют электронное согласование одновременно: В случае положительной визы всех согласующих, либо одного из согласующих, данные переходят на следующий этап согласования. В случае наличия хотя бы одной отрицательной визы, данные после визы всех пользователей, возвращаются на предыдущий этап. Согласование всеми сотрудниками на этапе или хотя бы одним, определять опционально, в настройках этапа. Механизм согласования должен позволять перенаправлять данные для согласования заместителю согласующего. Действует на определенный период, 26 устанавливается согласующим, либо администратором системы. В данный период задачи по согласованию сразу попадают к заместителю. Согласование каждому пользователю ограничивать сроками из регламента. В случае не согласования в отведенное регламентом время перенаправлять задачу на заместителя согласующего. Время, которое отводится заместителю на согласование может настраиваться опционально. В случае возникновения потребностей, выходящих за рамки лимита, выполнить следующие действия: либо утвердить дополнительный лимит затрат; либо определить потребность как аварийную. Согласование аварийных потребностей: Аварийные потребности должны проходить согласование: Либо по очень сокращенному маршруту; Либо уже по факту их исполнения. Вариант процедуры согласования аварийных потребностей настраивается в системе опционально. Настройку осуществлять в регистре сведений «Настройка организаций МТО», и вести в разрезе организаций. 4.2.7. Обеспечение потребностей (Часть процесса управление запасами). 4.2.7.1. Анализ складских запасов. Необходимо предоставить общий инструмент для анализа складских остатков, а так же анализа зарезервированного и находящегося в пути остатка. Данный инструмент должен помочь: Определять источники пополнения запасов; Анализировать возможные аналоги номенклатуры; Анализировать страховой запасы; Просматривать складские остатки в разрезе складов и организаций. Т.к. системой должна быть предусмотрена работа с минимальностраховыми запасами. Необходимо осуществить в системе возможность установки минимальных страховых запасов вручную или загрузкой из Excel. Для установки лимитов должны использоваться следующие поля: 27 Номенклатура; Склад; Количество; Количество для дозаказа. В обработке «Ввод и согласование потребностей» должна быть возможность с помощью кнопки «Заполнить под страховой запас» автоматически создать оперативные потребности. Далее провести процедуру согласования данных потребностей. Аналитика по потребности заполняется по параметрам пользователя, определенным для подстановки, либо до заполняется вручную. При согласовании данной потребности должен быть виден реквизит данной потребности «Для пополнения минимального страхового запаса». Страховой запас должен определяться на «Центральный склад». 4.2.7.2. Определение способа обеспечения потребностей В системе необходимо иметь механизм, который позволит после полного согласования оперативных потребностей, аккумулировать их и определить способы обеспечения данных потребностей. Данный механизм должен осуществлять отбор потребностей: По параметрам планирования; По способу закупки (централизованной, самостоятельной); В разрезе организаций; В разрезе ЦФО; В разрезе складов; В разрезе приоритетов (текущие, срочные, аварийные). Механизм обеспечения потребностей должен позволять обеспечивать потребности с разных складов, в рамках юридического лица пользователя. Так же в АСУ МТО должен храниться перечень «складов исключений», обеспечения с которых не должно выполняться. Использование «складов исключений» не допустит обеспечение потребностей Бригады А за счет свободных остатков Бригады Б, которые на текущий момент могут быть уже списаны но не отражены в АСУ МТО. В случае когда, появится необходимость обеспечения потребностей 28 Бригады А за счет свободных остатков Бригады Б, данные склады необходимо удалить из перечня «складов исключений». Механизм обеспечения потребностей должен: позволять анализировать свободные остатки на складах в единицах измерения остатков, и уже зарезервированный под потребность остаток. производить автоматический потребностям доступного расчет количества по на всем отобранным начало периода планирования, количества потребности, непокрытого количества, и предлагать расчет количества по способам обеспечения потребностей: o За счет свободных остатков; o За счет перемещения; o За счет закупа. Механизм обеспечения оперативных потребностей должен выводить: Требуемую дату исполнения потребностей, рассчитывается из потребности; Плановую дату исполнения потребностей, рассчитывать по формуле Текущая дата + Срок поставки + Срок перемещения между складами. Сроки поставки и сроки перемещения между складами необходимо хранить в системе, с возможностью изменения. (значения должны быть настраиваемыми) Так же механизм должен позволять высвободить зарезервированный остаток, для обеспечения аварийной потребности, но только с согласованием ответственных лиц. После обработки потребностей механизмом обеспечения в Системе должна храниться информация за счет чего данные потребности будут обеспечиваться: Остатки; Перемещение; 29 Закупка. Система должна контролировать количество обеспечиваемой потребности и блокировать действия пользователей при: Закупке большего количества, чем в потребности, с учетом уже закупаемого; Перемещение большего количества, чем в потребности, с учетом уже перемещенного; Списание большего количества, чем в потребности, с учетом уже списанного. Система должна хранить перечень «складов исключений», обеспечения с которых не должно выполняться. Хранить перечень в регистре сведений «Склады исключения», с набором реквизитов: Склад получатель; Склад отправитель. Использование «складов исключений» не допустит обеспечение потребностей Бригады А за счет свободных остатков Бригады Б, которые на текущий момент могут быть уже списаны но не отражены в Системе. В случае когда, потребуется обеспечения потребностей Бригады А за счет свободных остатков Бригады Б, необходимо установить флаг «не использовать склады исключения». Данный перечень заполняется/редактируется ответственными пользователями вручную. Механизм обеспечения потребностей должен позволять обеспечивать потребности остатком, зарезервированным под другую потребность. Для этого требуется установить флаг «Учитывать резерв». Результат обеспечения согласовать, с явным указанием согласующим, что данные потребности обеспечиваются за счет резерва. При выборе способа обеспечения закупки необходимо, чтобы система могла осуществить резервирование МТР под уже заказанные МТР (по потребности поддержания минимальных запасов на складе). Минимальный страховой запас может формироваться на центральный склад. 30 В Системе реализовать механизм определения и хранения номенклатуры в рамках Перечня №1, Перечня №2, Перечня №3. Данные перечни впоследствии будут использоваться как отборы для: Централизованной закупки (Перечень №1); Самостоятельной закупки (Перечень №2); Самостоятельной закупки (Перечень №3). В обработке «Ввода и согласования потребностей» добавить реквизит «Вид закупки». По умолчанию в данный реквизит подставлять значение из реквизита номенклатуры «Вид закупки». Значение данного реквизита записывать в документ «Потребность». В процессе согласования, согласующие не могут изменить значение реквизита потребности. В процессе обеспечения осуществлять отбор потребностей по способу закупки, централизованно или самостоятельно, используя реквизит «Вид закупки». 4.2.8. Выбор поставщика номенклатуры 4.2.8.1. Подготовка запроса поставщика В АСУ МТО.TMS для подготовки запроса поставщикам использовать документ «Заявка на закупку». Пользователи при создании документа могут определять следующие параметры: Способ оценки предложений; Дата оглашения результатов; Минимальное количество заявок; Предмет поставки; Поставка по месту; Электронный адрес; Сроки принятия предложений; Тип тендерных процедур Закупочная стратегия Предварительная квалификация 31 Параметр «Способ оценки предложений» представлен одноименным реквизитом с возможностью определения оценки оферт по минимальной цене, либо по бальной системе оценок. Для этого реализованы значения реквизита: Минимальная цена; Бальная оценка. Системой должен быть предусмотрен тип закупки как – Запрос предложений – разовая поставка, извещение в данном случае должно иметь основание, в данном случае потребность. Параметры «Ответственный», «График работы» и «Электронный адрес» представлены реквизитами «Ответственный», «График работы» и «e-mail:» соответственно. Данные реквизиты заполнять данными по пользователю, создавшему документ в АСУ МТО.TMS. Так же данные реквизиты будут использованы в печатных формах для информирования поставщиков. Параметры «Дата оглашения результатов» и «Минимальное количество заявок» будут представлены одноименными реквизитами. Реквизит «Дата оглашения результатов» будет выводиться в печатные формы для информирования поставщиков. Если количество предложений поставщиков меньше значения реквизита «Минимальное количество заявок», Система должна ограничивать создание документа «Протокол оценки предложений поставщиков» по данным торгам. Параметры «Предмет поставки» и «Поставка по месту» будут представлены реквизитами «Предмет поставки» и «Поставка по месту». Данные реквизиты будут заполняться ответственным за документ пользователем, после анализа состава Заявки на закупку. Документ «Заявка на закупку» позволит произвести процедуру «Выбора контрагентов» следующими способами: Выбор контрагента по решению ЗК по результатам сбора оферт; Выбор контрагента в рамках ЛФО; Выбор контрагента по решению ЗК на основании Критериев без альтернативности; 32 Выбор контрагента по решению Полномочного органа. Выбор контрагента по решению Конкурсной комиссии по результатам сбора оферт предполагает сбор оферт контрагентов путем: Открытого способа закупки; Внеконкурсной закупки. Добавить реквизит «Внеконкурсная закупка», с типом данных «Булево». В случае использования «Закрытых торгов» включать видимость закладки «Рекомендованные поставщики». На доступной закладке «Рекомендованные поставщики» определять круг контрагентов для проведения торгов закрытого типа. Заполнение табличной части закладки «Рекомендованные поставщики» производить двумя способами: Вручную; Автоматически. Используя ручной способ, пользователи смогут подобрать контрагентов из справочника «Контрагенты». Используя автоматический способ, пользователи смогут по кнопке «Заполнить предыдущими победителями» заполнить табличную часть перечнем последних контрагентов-победителей по номенклатуре, указанной в текущем документе. В механизмах интеграции с электронной торговой площадкой предусмотреть реквизит «Закрытые торги» можно будет использовать для ограничения видимости торгов, определенным кругом контрагентов. В АСУ МТО.TMS для Внеконкурсной закупки будет осуществлена рассылка писем по электронной почте, обозначенному кругу контрагентов. Рассылка писем будет осуществлена на электронные адреса контрагентов, полученных из регистра сведений «Контактная информация». Если у документа «Заявка на закупку» установлен тип закрытых торгов, но не указан ни один контрагент, или у указанных контрагентов отсутствует контактная информация, пользователю при сохранении документа вывести текстовое оповещение. 33 В АСУ МТО.TMS для закрытого типа торгов реализовать печатную форму, которая представлена Заказчиком. Выбор контрагента в рамках ЛФО предполагает выбор контрагента в рамках единоличного выбора Владельца ЛФО в рамках установленного для него ЛФО. Для реализации учета владельца ЛФО и суммы лимитирующей финансовую ответственность, а также сроков действия и определения заместителей создать регистр сведений «Владельцы ЛФО». В качестве реквизитов данного регистра использовать: Организация; Владелец ЛФО; ЛФО; Вид ЛФО; Заместитель; Период действия. Реквизит «Владелец ЛФО» будет иметь тип данных ссылка на справочник «Пользователи». Период действия ЛФО по умолчанию проставляется равным календарному году (01 января по 31 декабря). Начало периода может быть изменено пользователем, а окончание периода всегда равно окончанию календарного года (31 декабря). ЛФО может быть двух видов: Накопительный – предельный совокупный стоимостной лимит объема сделок; Разовый – предельный стоимостной лимит разовой сделки. Внесением данных в регистр сведений «Владельцы ЛФО» и их корректировкой будут заниматься пользователи с ролью «Комитет по договорной работе». В документе «Заявка на закупку» при выборе способа выбора контрагента в рамках ЛФО фиксировать владельца ЛФО, для осуществления контроля. 34 При сохранении документа «Заявка на закупку» осуществлять проверку на соответствие документа установленному ЛФО. В случае превышения суммы ЛФО информировать и отказывать в проведении документа. Контроль осуществлять в следующем порядке: первоначально по ЛФО с видом «Накопительный», если суммы в связке «Организация + Владелец ЛФО + Вид ЛФО + Период действия» отсутствует, тогда контролируем по ЛФО с видом «Разовый». Если АСУ МТО.TMS не находит сумму ЛФО вообще, тогда выдаем предупреждение об отсутствии установленной суммы ЛФО и отказываем в проведении документа «Заявка на закупку». Проведение процедуры Выбор контрагента в рамках ЛФО предполагает сбор оферт, открытого или закрытого типа. Сбор оферт позволит выполнить предварительную квалификацию контрагента и проверку контрагента Подразделением безопасности. Данный механизм реализован в АСУ МТО.TMS документами «Предложение поставщика» и «Протокол оценки предложений поставщиков». В АСУ МТО.TMS использовать документ «Заявка на закупку» со способом решение полномочных органов. Реквизит «Закрытые торги» при данном способе будет автоматически установлен, и не будет доступен для снятия. Следующим шагом в процедуре будет фиксация оферты поставщика. В АСУ МТО.TMS отражается регистрацией документа «Предложение поставщика». В АСУ МТО.TMS реализовать печатную форму «Котировочная спецификация» ООО «Газпром Бурение». С возможностью выгрузки в формат EXCEL и загрузки в систему уже заполненных предложений по данному документу. Фиксация выбора контрагента по решению ЗК на основании критериев безальтернативности в АСУ МТО.TMS возможна двумя способами. Пользователи могут провести процедуру выбора поставщика посредством сбора оферт и определения победителя с указанием в комментариях критерия безальтернативности. Так же пользователи системы с ролью «Организатор тендерных процедур» могут внести данные в регистр сведений «Монопольные 35 поставщики». Работа с регистром «Монопольные поставщики» описана в следующем пункте проектного решения. В документах сотрудников, «Заявка ответственных на закупку» реализовать механизм учета за закупку и обеспечение номенклатуры пользователей. Данный механизм должен накладывать отбор на доступность потребностей, при подборе их в состав Заявки на закупку. Назначение сотрудника, ответственного за закупку и обеспечение номенклатуры, выполнять на определенный период. Если конечная граница периода не указана, значит, период действия данной записи не органичен. Данный механизм будет реализован с использованием регистра сведений «Ответственные за закупку». Доступ к данному регистру сведений будет предоставлен сотрудникам с ролью «Менеджер по закупкам». Документ «Заявка на закупку» согласовывать службой безопасности БЕ. В случае если маршрут согласования для типа документа определен. Тогда документ проходит согласования и выполняет рассылку оповещений по электронной почте после финального согласования. Интеграция с электронной торговой площадкой также должна выполнять только по согласованным до финальной стадии документам. Если маршрут по типу документа не определен, тогда выполнять все движения и операции по факту проведения документа. 4.2.8.2. Учет неквалифицированных поставщиков В АСУ МТО.TMS фиксировать и хранить список неквалифицированных поставщиков. Данный список вести в разрезе периода и набора критериев, по которым не пройдена квалификация. Предоставить возможность ответственным сотрудникам выполнять ручную квалификацию поставщиков, не теряя истории. В регистре сведений «Квалифицированных поставщиков» добавить колонку «Квалифицирован». Данную колонку заполнять вручную, только пользователям с ролью «Служба безопасности». Для ручной корректировки регистра сведений «Квалифицированных поставщиков» использовать рабочее место «Квалификация поставщика». 36 Рабочее место «Квалификация поставщика» использовать сотрудникам подразделения безопасности БЕ, с ролью «Служба безопасности». Рабочим местом «Квалификация поставщика» обрабатывать все документы «Предложение поставщика». Регистр сведений «Квалифицированные поставщики» заполнять следующими данными: «Организация»; «Заявка на закупку»; «Номер Заявки на закупку»; «Поставщик»; «Критерий дисквалификации»; «Дата дисквалификации»; «Дата окончания дисквалификации»; «Не квалифицирован системой»; «Ответственный»; «Тип риска»; «Размер предоплаты»; «Расшифровка риска»; «Стоп информация»; «Заключение»; «Проверка завершена»; «Надежен»; «Квалифицирован». Реквизит «Критерий дисквалификации» заполнять критерием, по которому не пройдена квалификация. Реквизит «Дата дисквалификации» заполнять датой документа «Предложение поставщика». Реквизит «Дата окончания дисквалификации» заполнять 31 декабря года из даты дисквалификации. 37 Реквизит «Не квалифицирован системой» заполнять автоматически, в случаях, если поставщик не заполнил значения обязательных критериев. Если контрагент не квалифицирован системой, тогда реквизиты «Ответственный», «Тип риска», «Размер предоплаты», «Расшифровка риска», «Стоп информация», «Заключение» и «Надежен», не заполняются. Реквизит «Ответственный» заполнять пользователем, осуществляющим работу с рабочим местом «Квалификация поставщика». Реквизит «Тип риска» заполнять значением, указанным пользователем, из перечисления: Регистрации; Криминальный; Финансовый; Истории. Реквизит «Размер предоплаты» доступен для заполнения, только если «Тип риска» равен значению «Финансовый». Использовать в качестве значений перечисление «Размер предоплаты», с вариантами: «без предоплаты и до 500 000 руб.»; «от 500 000 руб. до 5 000 000 руб.». Реквизит «Расшифровка риска» заполнять пользователями вручную, посредством рабочего места «Квалификация поставщика». Реквизит «Стоп информация» заполнять значениями перечисления «Стоп информация», с вариантами: «Не выявлено»; «Условный риск»; «Безусловный риск». Реквизит «Заключение» заполнять пользователями вручную, указываю текстовую информацию. Реквизит «Надежен» заполнять пользователям вручную, определяя значение «Да» или «Нет». 38 Реквизит «Проверка завершена» заполнять значениями «Да» или «Нет», вручную. Реквизит «Квалифицирован» заполняется пользователями вручную, для тех поставщиков, которые зафиксированы системой как неквалифицированные. Ограничить заполнение документа «Протокол оценки предложений поставщика». В табличную часть должны попадать только предложения, по которым у поставщиков в регистре сведений «Квалифицированные поставщики», в реквизите «Проверка завершена» установлено значение «ДА» и в реквизите «Стоп информация» установлено значение «Не выявлено». Реквизит «Проверка завершена» нельзя установить в значение «Да», если: Не заполнен реквизит «Стоп информация»; Не заполнен реквизит «Расшифровка риска», для указанного риска. Запретить изменение исторических записей регистра, после установки значения «Да» в реквизите «Проверка завершена». Если реквизит «Тип риска» установлен в значение «Регистрация», тогда реквизит «Стоп информация» может принимать только значение «Безусловный риск». В рабочем месте «Квалификации поставщиков» предоставить механизм отборов и сортировок, для обрабатываемой информации. Автоматически устанавливать отбор по реквизиту «Организация». Значение реквизита брать из параметров пользователя. Так же добавить возможность отбора по реквизитам: «Дата»; «Номер Заявки на закупку»; «Поставщик». Вывод обрабатываемой информации обеспечить отчетными формами: «Еженедельный отчет»; «Ежемесячный отчет»; «Реестр договоров»; «Анализ изменения стоп-информации и риски». 39 Блоки колонок заключений о «Количество благонадежности проеденных торгов», контрагента» «Подготовлено и «Количество договоров/ДС/Спецификаций», представляют собой раздельные данные в одном отчете. Данный этих групп колонок не имеют логической связи между собой. Необходимо разработать форму отчета «Ежемесячный отчет» Реквизит «Сумма снижения» рассчитывается по формуле: «Сумма лота по решению ЗК»/ 100 ∗ «% предоплаты в Лоте» − «Сумма лота по решению ЗК»/ 100 ∗ «% предоплаты по решению ЗК» Пример: на лоте контрагент заявился на 10000 с предоплатой в 30%, на ЗК при переторжке он выиграл торги с суммой 8000 и 20% предоплаты, тогда сумма снижения равна: 8000/100 ∗ 30 − 8000/100 ∗ 20 = 800. Необходимо разработать форму отчета «Реестр договоров». Необходимо разработать форму отчета «Анализ изменения стоп- информации и риски». При заполнении набора критериев оценки поставщиков учитывать разность и специфику критериев оценки: Критерии с определённым набором значений. Каждому критерию будет установлен набор значений и указан бал, для расчета, при выборе определённого значения. Критерии допуска. Критерии, от заполнения или не заполнения которых будет зависеть, будет ли данный поставщик участвовать в коммерческой оценке. В случае не прохождения поставщика по критерию допуска, данный поставщик попадает в перечень неквалифицированных поставщиков. В документе «Протокол оценки предложений поставщика» на закладке «Оценка предложений поставщиков» вывести реквизит «Допущен к участию». Данный реквизит позволит разделить поставщиков прошедших и не прошедших квалификацию. Поставщики не прошедшие квалификацию не будут допущены к участию в торгах. Если Филиал или ЦАО заинтересованы в участии данного 40 поставщика, следует обратиться к пользователям с ролью «Служба безопасности». Вести учет версий документов для хранения истории, вносимых изменений. Данный механизм должен работать в «тонком клиенте» системы АСУ МТО. 4.2.8.3. Учет монопольных поставщиков Учет монопольных поставщиков в системе должен быть реализован следующим образом: Должна быть предоставлена возможность фиксировать данные в специально подготовленном регистре «Монопольные поставщик». Данные в этот регистр будут заноситься вручную: Номенклатура; Поставщик; Период; Ответственный. Так же в системе необходимо предусмотреть отдельную настройку, которая будет определять возможность использовать монопольных поставщиков в работе. Добавить реквизит «Учет монопольных поставщиков» с типом данных «Булево». Реквизит будет размещен в регистре сведений «Настройки организаций МТО». 4.2.8.4. Формирование предложений поставщиков Системой должно быть предусмотрены два способа формирования предложений контрагентов, участвующих в торгах: Ввод автоматически. В данном случае должна быть настроена интеграция с электронной торговой площадкой. Ручной ввод. В случае ввода предложения поставщика в Систему вручную. Реализовать возможность заполнения табличной части документа из файла формата .xls. Необходимо учитывать параметры: Объект-основание; Тип цен; 41 Валюта; Контрагент; Состав лотов (Номенклатура, цены); Критерии оценки; Требования к документации. Вводить предложений поставщиков в АСУ МТО необходимо только после окончания тендерных процедур. В случае автоматического ввода путем получения данных с Электронной торговой площадки (ЭТП) необходимо получать информацию о Контрагенте (Наименование, ИНН, КПП), номенклатуру (и аналоги, предложенные контрагентом), цены. После подведения итогов, информация о статусе тендерной процедуре должна отобразиться на ЭТП. В Системе необходимо учитывать обязательность заполнения значения, критерия оценки поставщика. При формировании предложений поставщиков информировать пользователя о не заполненном значении, но не ограничивать последующие действия. Предложения поставщиков с содержанием критериев, обязательных для заполнения, но с пустым значением, нельзя учитывать в последующей обработке и участии в торгах. Необходимо вести учет версий документов для хранения истории вносимых изменений. В табличной части документа предоставить механизм уменьшения, увеличения, деления и умножения цен на определённый пользователем процент или единицу валюты как по документу в целом, так и по отдельно взятым позициям. Системой должны быть предусмотрены следующие типы предложений: Основное Альтернативное. Система должна контролировать, чтобы в документе «Протокол оценки предложений поставщиков» участвовал один документ «Предложение поставщика» от поставщика в рамках одного и того же документа «Заявка на закупку», но различать по типу предложений. При сохранении документа 42 «Протокол оценки предложений поставщиков» информировать пользователя в случае наличия двух документов «Предложение поставщика» от одного поставщика. 4.2.8.5. Формирование протокола оценки предложений В документе «Протокол оценки предложений поставщиков» разделить закладку «Оценка поставщиков» на две: Оценка критериев поставщиков; Оценка благонадёжности поставщиков, Оценка цен поставщиков, Оценка цен поставщиков должна проводиться в динамическом режиме и выводить результаты Оценки критериев и благонадёжности на форму протокола оценки предложений. Системе необходимо подсвечивать минимальную стоимость предложения, с учетом результатов квалификации. А также иметь возможность для обозначения рекомендаций и автоматический подсчет стоимости лота по рекомендации Пользователя. Требуется вывести на форму документа реквизит «Стоимость лота». Реквизит выводиться для информации пользователей и не доступен для редактирования. Расчет реквизиты выполняется автоматически по формуле «Стоимость лота» = Номенклатура №1 («Плановое количество номенклатуры» * «Минимальная цена по номенклатуре») + … + Номенклатура № N («Плановое количество номенклатуры» * «Минимальная цена по номенклатуре») Параметр «Плановое количество номенклатуры» система получит из первоначального лота, сформированного документом «Заявка на закупку». Параметр «Минимальная цена по номенклатуре» система получит путем анализа цен, указанных в документах «Предложение поставщика», и выбора минимальной. Параметр «N» позволит пройти системе по всей номенклатуре, указанной в лоте, сформированного документом «Заявка на закупку». 43 Тем самым Система сможет проанализировать минимальные цены по каждой номенклатуре и составит минимальную стоимость лота. Далее эта стоимость будет использована для информативного вывода в реквизит документа «Протокол оценки предложений поставщиков». Оценка проводится по принципу соответствия всем критериям квалификации. Если поставщик не соответствует хотя бы одному из критериев, квалификация считается не пройденной. Для участия не квалифицированного поставщика в оценке, пользователи с ролью «Служба безопасности» должны установить значение «Поставщик квалифицирован повторно». Документ «Протокол оценки предложений поставщиков» использовать для фиксирования: Результатов квалификации; Выбранного контрагента-победителя; Для способа выбора поставщиков в рамках ЛФО, указанный в документе «Заявка на закупку» «Владелец ЛФО» автоматически попадет в состав согласующих документа «Протокол оценки предложения поставщика». Владелец ЛФО в случае согласования документа «Протокол оценки предложения поставщика» берет на себя ответственность за эффективность принятого решения и обязан обосновать причины выбора контрагента в случае запроса руководителя или аудиторской проверки. В качестве победителя могут быть выбраны поставщики исключительно из числа квалифицированных, т.е. с установленным флагом «Допущен», на закладке «Оценки предложений поставщиков». На закладке «Состав комиссии» отслеживать список согласующих лиц и статус согласования, каждым из них. Табличная часть будет заполняться автоматически по параметрам маршрута согласования документа. Предполагается добавление колонки «Статус согласования». Согласующим лицам для просмотра будут доступны значения критериев на закладке «Оценка критериев поставщиков», без значений баллов и суммарных итогов. Пользователям с ролью «Служба безопасности» доступна закладка «Оценки предложений поставщиков», но без колонки «Балл». Полностью документ будет доступен пользователям с 44 ролью «Организатор ответственным за тендера», текущий а также документ пользователь «Протокол должен оценки являться предложений поставщика». В Системе реализовать печатную форму Протокола оценки. 4.2.8.6. Формирование Прайсов. Документ «Прайс» может формироваться на основании Заявок на закупку, где установлен флаг «Прайс». Механизм формирования спецификаций в АСУ МТО должен зафиксировать и хранить следующие данные: Цены в разрезе номенклатуры; Условия поставки (тип цен, валюта, параметры учета НДС); Условия оплаты (даты оплаты, процент оплаты); Документы Заказ поставщику; Система должна контролировать следующие параметры: Наличие цен, по всем номенклатурным позициям спецификации; Тип цен должен быть равен типу цен, заданному при формировании потребности; Валюта должна быть равна валюте, заданной при формировании потребности; Дата оплаты не должна быть ниже текущей; Процент оплаты должен равняться 100%, в рамках одной номенклатуры; Даты формируемых документов, не должны быть меньше текущей. В форму документа справочника «Прайс», вывести реквизиты, получаемые по результатам процедуры «Выбора поставщика»: Поставщик; Договор; Условия оплаты; Срок поставки; Дата действия цены До; 45 Условия поставки. Данные реквизиты должны быть унаследованы «Заказом поставщику». На основании введенных Систему данных необходимо разработать печатную форму согласно требованиям Заказчика. 4.2.9. Выполнение закупки. После того как потребности распределены к закупке, их должен обработать закупщик. Разработать механизм, который позволит вести учет ответственных за закупку и обеспечения номенклатуры пользователей. Закрепить в соответствие с Номенклатурой, номенклатуры. или номенклатурной группой, или перечнем (1,2,3) Данный механизм должен накладывать отбор на доступность потребностей, при подборе их в состав лотов. Назначение ответственного за закупку и обеспечение номенклатуры, выполнять на период. Если конечная граница периода не указана, значит, период действия данной записи не органичен. Предусмотреть возможность замещения. Пользователям с ролью «Менеджер по закупкам» реализовать рабочее место в виде обработки «Рабочий стол Закупщика». Пример на рис. «Функционал Рабочего стола закупщика». Данная обработка должна выгружать на рабочий стол информацию к закупке ответственному за закупку. 46 Пользователь должен обработать потребности. В случае наличия Прайсов по номенклатуре потребности, должны сформироваться «Заказы поставщику», а в случае их отсутствия «Извещение» для проведения тендерных процедур. Формирование заказа поставщику После выполнения операция по определению потребностей, которые будут обеспечиваться за счет закупки, и определения поставщика, в АСУ МТО необходимо зафиксировать объём и перечень номенклатуры для закупки. При последующей работе с данным перечнем необходимо иметь возможность видеть: Комментарии, оставленные инициатором при формировании потребности; Приоритет потребности; Файлы, прикрепленные к потребности на этапе ввода; Текущий статус каждой строки заказа (например: строка №1 «Поставщик подтвердил», строка №2 «В Пути», и т.д.; информация предоставляется поставщиком при контакте с ответственным менеджером по закупке, и заносится менеджером по закупке вручную); Дата изменения текущего статуса (рассчитывается и фиксируется автоматически при изменении статуса строки менеджером по закупкам). Пользователь системы при формировании заказа поставщику должен работать только с потребностями определенными для закупки. Потребности, определенные для обеспечения за счет собственных остатков или перемещения, не должны быть доступными для закупки не зависимо ни от каких параметров. При проведении документа отправлять электронное сообщение, «Заказ на поставщику», электронный формировать адрес и поставщика, указанный в его контактных данных. В случае отсутствия электронной почты в контактных данных поставщика выводить сообщение, но не блокировать проведение документа. Учитывать факт отправки письма, чтобы не отправлять письма постоянно, при каждом перепроведении. 47 В связи с условиями по временному ограничению действия договора, при проведении документа «Заказ поставщику» проверять временные рамки действия выбранного договора. В случае выхода текущей даты (или даты, в шапке документа) за рамки периода действия договора, при проведении выдавать сообщение пользователю и отказывать в проведении. Система АСУ МТО.TMS должна контролировать превышение суммы договора. В шапке документа «Заказ поставщику» кроме договора выводить и документ «Спецификация договора поставки». Связка данных реквизитов позволит контролировать заказываемую номенклатуру, ее количество и превышение суммы договора. Для случаев, когда номенклатура отсутствует в спецификации или ее количество больше чем в спецификации отказывать в проведении документа «Заказ поставщику» и выводить информационное сообщение. Для случаев превышения суммы договора, с учетом ранее проведенных документов «Заказ поставщику», так же отказывать в проведении документа и выводить информационное сообщение. Описанные выше контроли по сумме, количеству и номенклатуре, регулировать опциональной настройкой. В табличной части документа «Заказ поставщику» вести учет статусов каждой строки отдельно. Данный функционал позволит контролировать статус исполнения поставщиком и отслеживанием собственными силами процесса поставки. При создании документа «Заказ поставщику» у всех строк автоматически будет проставляться статус «Создан». При нажатии на кнопку «Отправить поставщику» АСУ МТО.TMS будет отправлять печатную форму документа на электронную почту контрагента, и устанавливать статус строк «Отправлено поставщику». В дальнейшем установкой статуса сможет заниматься пользователь, ответственный за созданный документ. Кроме статуса, добавить в табличную часть документа «Заказ поставщику» колонки «Дата изменения статуса» и «Решение». Реквизит «Дата изменения статуса» закрыть от редактирования вручную. Изменения реквизита производить автоматически по текущему времени изменения статуса строки. Реквизит «Решение» сделать текстовым полем, для внесения комментариев по каждой строке заказа. 48 Реквизиты «Статус», «Дата изменения статуса» и «Решение» выводить в отчетную форму документа «Анализа заказов поставщикам». В качестве статусов использовать значения: Создан; Отправлен поставщику; В производстве; В пути; Поступил на склад. 4.2.9.1. Корректировка/Закрытие заказа поставщику Механизм Корректировка/Закрытие заказов поставщику, в АСУ МТО, необходим для внесения корректировок в перечень заказанной у поставщика номенклатуры, в случаях недопоставки (когда поставщик сказал, что точно не сможет поставить 100 шт., а только 95 шт.). С помощью документа «Корректировка заказа поставщику» можно провести корректировку заказа, связанную с изменением товарных и финансовых договоренностей с поставщиком. Документ всегда вводится на основании документа «Заказ поставщику». При вводе на основании табличная часть документа заполняется теми потребностями из документу «Заказ поставщику», на основании которого он введен, по которым не было оформлено поступление товаров. При этом учитываются все ранее введенные документы корректировки. Документ «Корректировка заказа поставщику» решает две основные задачи: добавление и удаление позиций в табличную часть документа «Заказ поставщику». Если требуется добавить в заказ поставщику позицию номенклатуры, в табличную часть документа "Корректировка заказа поставщику" вводится строка с положительным значением реквизита "Количество", значение реквизита соответствует количеству добавляемых позиций. Если требуется удалить из заказа поставщику позицию номенклатуры, в табличную часть документа "Корректировка заказа поставщику" вводится строка 49 с отрицательным значением реквизита "Количество", значение реквизита соответствует количеству удаляемых позиций. Если требуется произвести замену позиции номенклатуры в заказе поставщику, в табличную часть документа «Корректировка заказа поставщику» вводится две строки: позиция, которую нужно удалить, вводится со знаком минус, а позиция, которую нужно добавить вводится со знаком плюс. При корректировке цены или количества по позиции номенклатуры в табличную часть заказа, также вводится две строки: строка со старой ценой или количеством со знаком минус и строка с новым количеством или ценой со знаком плюс. Для автоматического заполнения табличной части документа «Корректировка заказа поставщику» предназначена кнопка «Заполнить». Возможны два варианта заполнения: Заполнить по остаткам; Скопировать состав заказа. Вариант «Заполнить по остаткам» - в этом случае табличная часть документа заполняется всеми недополученными товарами по документу «Заказ поставщику», указанному в шапке документа, с учетом ранее оформленных документов корректировки. Вариант «Скопировать состав заказа» - в этом случае в документ будет скопирована информация из табличной части документа «Заказ поставщику». 4.3. Функциональные требования к блоку «Управление запасами». Система должна включать в себя средства для управления топологией склада, параметрами товарной номенклатуры, планирования складских операций, управления ресурсами, применения различных методик хранения, идентификации и обработки грузов. Система должна позволять управлять складской логистикой в рамках различных технологических процессов (приём и отгрузка товара, внутренние перемещения) в реальном времени. Система должна позволять использовать механизмы Штрихкодирования, RFID. Необходимо также предусмотреть возможность работы со складом-магазином, как сторонней организацией, но возможностью ввода информации. 50 4.3.1. Регистрация поступления товаров и услуг Реализовать регистрацию факта поступления ТМЦ на склад путем ввода в Систему документа «Поступление товара и услуг». Данный документ должен учитывать потребности, под которые пришли ТМЦ, для последующего присвоения статуса этим потребностям. Система должна предусматривать следующие типы учета МТР на складах: Учет накопительным итогом, стоимость МТР должна рассчитаться автоматически по среднему значению; Партионный учет, учет по характеристикам и стоимости каждой партии. Должна быть реализована возможность хранения перечня товаров, по которым нельзя производить приемку товаров без сертификатов, и контроль поступления товаров из данного перечня при приемке с опциональной загрузкой скан-копии сертификатов. Обязательность загрузки скан-копий определять опцией «Контролировать сертификат» в элементе справочника Номенклатура. Если в табличной части документа имеется хотя бы одна номенклатура с установленным реквизитом «Контролировать сертификат» и не приложен электронный документ, то отказать в проведении документа «Поступление товаров и услуг» и вывести сообщение пользователю. В Системе фиксировать номер и дату входящей счет фактуры, при поступлении ТМЦ. Номер С/Ф вх.; Дата С/Ф вх. Реализовать возможность при поступлении ТМЦ на склад выбирать нормализованную номенклатуру из справочника и указывать наименование поставщика для недопущения нарушения законодательства РФ. Но дальнейшие действия и учет должны осуществляться по нормализованной записи из Справочника. Предусмотреть возможность постановки на ответ хранение в случае поступления бракованных МТР. (В документе приходный ордер предусмотреть 51 возможность установки флага «Брак»). На основе данного документа формировать ТОРГ-1. В случае поставки раньше запланированного срока, предусмотреть возможность автоматического расчета за ответ-хранение, по ранее установленным тарифам в системе. 4.3.2. Распределение ТМЦ по потребностям Необходимо разработать механизм, который позволит обеспечивать потребности путем перемещения остатков ТМЦ или списания их. Данный механизм должен позволять определять, потребности какого ЦФО, и какого склада необходимо обработать. Также механизм распределения должен автоматически рассчитать: Количество потребности; Количество свободного остатка, по номенклатуре потребности; Количество зарезервированного остатка; Необеспеченное количество; Количество, обеспеченное остатками; Количество, обеспеченное перемещением. По результатам работы данного механизма у распределенных потребностей необходимо изменить статус для отображения и отслеживая в отчетах. Статус в данном случае может быть представлен двумя вариантами: На передаче, в случае обеспечения потребности свободными остатками, в рамках собственного склада; На перемещении, в случае обеспечения потребности за счет перемещения с других складов, в рамках организации. Так же по результатам работы механизма распределения должны сформироваться Задание на перемещение МТР, с привязкой к определенным потребностям. Данные перечни должны пройти процедуру согласования, после чего должны быть исполнены. В случаях если приоритет потребностей в перечне 52 аварийный, согласование может проходить параллельно исполнению или постфактум. Механизм распределения ТМЦ по потребностям должен контролировать распределяемое количество, которое не должно превышать количество свободного остатка, даже в случае наличия большего количества в потребности. Документы «Задание на перемещение» должны выполнять резервирование свободного остатка под потребность. Данные документы возможность согласования, для утверждения должны иметь результатов обеспечения потребностей. При согласовании документов до финальной стадии в системе автоматически формировать документы «Перемещение товаров», отражающие фактическое исполнение потребности. Впоследствии пользователь с ролью «Менеджер по управлению запасами» будет их проверять и проводить. После проведения документов будут отражены движения по перемещению МТР между складами. Документы должны контролировать свободный остаток и не позволять резервировать больше чем есть возможность. Система не должна позволять формировать минусовой резерв. На основании документов «Задание на перемещение» должна формироваться заявка на транспорт. При перемещении между складами разных филиалов документ «Задание на перемещение» при признаке «Межфилиальное перемещение» должен пройти обязательное электронное согласование, иметь определенную печатную форму, согласно требованиям Заказчика. Необходимо также предусмотреть ориентировочный расчет стоимости перевозки, в данном документе, используя расчет с использованием реквизитов из блока «Управление транспортом». 4.3.3. Перемещение ТМЦ на основании потребности Механизм перемещения товаров регистрирует перемещение товаров между складами организации. В документе указывается перечень перемещаемых товаров со ссылкой на потребность, а также ее параметры. 53 Для сокращения временных затрат пользователей АСУ МТО необходимо предоставить возможность работы на основании данных полученных на этапе распределения ТМЦ потребностей. А именно, разработать «рабочий стол сотрудника Склада», где будут консолидироваться все задания на перемещения с его склада. Т.е. у каждого кладовщика должны быть доступны только те «Задания на перемещения», к которому у него есть доступ. «Рабочий стол сотрудника Склада» должно разрешать на основании нескольких заданий формировать одно «Перемещение». Табличная часть документа «Перемещение» должна содержать информацию: Номенклатура; Количество; Документ резерва; (в возможностью открытия документа из документа) Цена. Механизм перемещения товаров должен выполнять контроль количества перемещаемой номенклатуры с количеством остатка потребности, чтобы не допустить минусовых остатков на складах. Дата и номер документа «перемещения», присваиваются автоматически, при записи документа. В документе предусмотреть возможность отметки даты и времени отправки груза и поступления. Отметка о получении груза должна зафиксировать факт перемещения ТМЦ, указанных в данном документе и осуществить перемещение. Дата документа не равна дате проводки документа (дате получения). В журнал документов вывести индикацию о получении. Отметку об отправке должен проставить сотрудник склада. Отметку о получении сторона получатель. При установки отметки о получении должна появиться возможность загрузки скана документа с подписью и печатью (настраиваемая опция). 54 Иные перемещения (между складами) не требующие потребность должны осуществляться с использованием заданий на перемещение без привязки к потребности. Необходимо предусмотреть возможность формирования документа «Комплектация» для комплектовщиков, на основании которого возможно формирование документа «Перемещение». 4.3.4. Формирование ТТН. Разработать механизм, позволяющий формировать ТТН на основании документов перемещения и Заданий на работу транспорта/спецтехники. При выборе задания на работу, предполагается автоматическая подстановка реквизитов «Организация», Место отправки, Склад получатель = «Задание на работу.Маршрут.Получатель». Если рейс будет создаваться новый, то пользователь выбирает перемещения из табличной части обработки. Отбор по перемещениям по умолчанию: Период = «Из шапки обработки», Флаг прибыл = «Нет», Пометка удаления = «Нет». Заполняет реквизиты: Подрядчик Транспортное средство. Водитель Затем, пользователь после выбора документов перемещения должен сформировать ТТН. Механизм должен установить флаг «отправлен» в документах перемещений участвовавших в обработке от имени пользователя. Пользователь получатель должен проверить количество прибывшего товара с количествами в документах «перемещений МТР» с флагом «отправлен». Если количества совпадают, то устанавливается флаг «Прибыл». При установке флага прибыл и проведении документа Перемещение МТР, по нему находится Задание на работу в которое он включается, проверяется если все Перемещения по этому заданию «Прибыли», то по Заданию на работу находится Рейс, и к этому рейсу создается и проводится документ «Прохождение точки маршрута». Таким образом установив во всех перемещениях флаги 55 «Прибыл» - Рейс, который их перевозил, автоматически перейдет в Завершен, и как следствие в завершен перейдут Задания на работу из этого рейса. 4.3.5. Списание ТМЦ. Списание материалов должно осуществляться с использованием документа «Задание на списание». Далее (Материальный для формирования отчёт, М-29) документа разработать «Требование механизм, накладная» позволяющий за определенный период осуществлять подбор документов «Задание на списание» и формировать требования накладные. По выбранному списку номенклатур из документов «Задание к списанию» создает один документ «Требование-накладная» на каждый из типов номенклатур МПЗ, СИЗ/Хозинвентарь, ГСМ. В обработке доступные к отбору фильтры: Организация, Склад отправитель, Номенклатура. В обработке состав табличной части: Номер документа «Задание к списанию» с возможностью установить флаг для выбора, Потребность, вид покрытия, дата, номенклатура, Код НСИ, склад отправитель, количество из документа, количество списать (поле редактируется), количество уже списано, у флаг отработано (не редактируется и устанавливается если строка уже полностью включена в какой либо документ «Требование-накладная». Разрешается редактировать количество и включать в документ «требование-накладная» частичные количества из строк документа «Задание к списанию», либо переносим все количество из документа Задание к списанию, либо все количество оставляем для другого документа «Требование-накладная». Разрешается выбирать номенклатуры разных типов, при выполнении создания консолидированного документа они должны распределиться по типам (МПЗ, СИЗ/Хозинвентарь, ГСМ) в отдельные документы Требования-накладная. В результате объединения создаются не проведенные документы Требование-накладная от одного до трех в зависимости от типа номенклатур, которые были выбраны. 56 Документы «Требования накладные» должны иметь возможность прикрепления файлов, а также возможность электронного согласования. Необходимо также предусмотреть возможность электронного согласования данных документов. При согласовании происходит проведение документа. После проведения документ регистрируется к обмену в Бухгалтерскую систему Заказчика. Для документов разработать печатную форму согласно требованиям Заказчика. 4.3.6. Инвентаризация ТМЦ на складах. Документ «Инвентаризация товаров на складе» предназначен для проведения инвентаризации на оптовых, розничных складах. Документ «Инвентаризация товаров на складе» предназначен для формирования и печати сличительной ведомости и инвентаризационной описи при проведении инвентаризации на складах организации, а также выписки актов списания и оприходования излишков на основании данного документа при наличии расхождений между фактическими и документально подтвержденными остатками номенклатурных позиций. Данные в инвентаризационной ведомости можно автоматически заполнить информацией об остатках позиций номенклатуры на указанном в документе складе с помощью кнопки «Заполнить». Данные об остатках позиций номенклатуры отображаются в графе «Количество по данным учета» и не редактируются. В графу «Количество» заносятся реальные остатки на складах, полученные в результате проведенной инвентаризации. В графе «Отклонение» фиксируется отклонение между реальным остатком, зафиксированном в результате поведения инвентаризации и остатком по данным учета. В графу «Учет. Сумма» выводится информация о суммарной себестоимости, рассчитанной на основании введенных в информационную базу документов. 57 В графу «Сумма» заносится реальная суммарная себестоимость, по которой номенклатурная позиция учитывается на складе. На основании этого параметра и фактического количества рассчитывается поле «Цена». Возможен и другой способ заполнения, когда вводится фактическая цена и на основании ее и введенного фактического количества рассчитывается суммарная фактическая себестоимость. Данные о суммарной фактической себестоимости отражаются в печатной форме инвентаризационной ведомости в графе «Фактическое наличие». По результатам проведение документа инвентаризации можно выписать подчиненные документы: «Списание товаров» и «Оприходование товаров». Состав этих документов будет заполнен согласно результатам проведения инвентаризации, то есть в табличную часть документа «Оприходование товаров» будет занесен излишек номенклатурных позиций, выявленный в результате инвентаризации, а в табличную часть документа «Списание товаров» будут занесены те номенклатурные позиции, которые необходимо списать по результатам проведенной инвентаризации. После проведения этих документов, количество номенклатурных позиций на складе установится равным реальному количеству, зафиксированных в инвентаризационной ведомости. Документ «Оприходование товаров» предназначен для оформления факта оприходования материальных ценностей на склад. Ввод документа «Оприходование товаров» возможен при помощи операции «Ввод на основании» документа «Инвентаризация товаров на складах». Документ «Списание товаров» предназначен для оформления списания товаров. Документ может быть оформлен на основании проведенной инвентаризации или как свободный документ в случае произвольного списания товаров. Табличная часть документа заполняется стандартным образом – построчным вводом или подбором из справочника «Номенклатура» (кнопка «Подбор»). 58 При подборе из справочника можно установить вариант подбора, при котором будут показываться только те товары, которые имеются в наличии на складе («По остаткам номенклатуры»). В том случае, если документ оформляется на основании документа «Инвентаризация товаров на складе», его табличная часть автоматически заполняется в соответствии с данными, указанными в инвентаризации. 4.3.7. Учет аналогов в АСУ МТО В Системе требуется разработать механизм подбора аналогов для этапов: Обеспечения потребности; Выбора поставщика; Выполнения закупок. Указание аналогов номенклатуры должно производиться из карточки номенклатуры. Для каждого элемента справочника будет доступна ссылка на регистр, в котором возможно будет указать замену. Возможность замены аналогом не должна иметь временных рамок, а определяться только наличием соответствующей записи в регистре. Таким образом, для прекращения возможности замены аналогом номенклатуры – не использовать запись, но хранить для истории. У одного элемента справочника Номенклатура возможно наличие нескольких записей с аналогами. Обеспечить подбор аналогов в документах «Обеспечение заявочных компаний», «Распределение МТР». Для данных документов предоставить функционал обеспечения потребностей только за счет указанной номенклатуры либо с учетом возможных аналогов. Способ будет указываться опционально. В документе «Заявка на закупку» для оповещения поставщика о возможности предложения аналога, к указанной в потребности номенклатуре, добавить в табличную часть реквизит «Аналог». Данный реквизит будет добавляться инициатором документа вручную. В документе «Предложение поставщика» разработать функционал, позволяющий указать номенклатуру-аналог для заявленной потребности. Подбор 59 номенклатуры осуществлять вручную, по комментариям поставщика. Для этого добавить в табличную часть реквизит «Аналог». Если данный реквизит установлен, тогда пользователям доступен выбор аналога к номенклатуре потребности. Данный документ может вносить изменение в регистр. В документе «Заказ поставщику» требуется возможность указывать аналог. Добавить в табличную часть возможность установки флага «Аналог», при положительном значении которого, будет возможность указать номенклатуруаналог. Предоставить функционал, позволяющий контролировать аналоги для удовлетворения потребностей: Для этапа «Обеспечения потребностей» в документах «Обеспечение заявочной компании» и «Распределение МТР»; Для этапа «Выполнения закупок» в документе «Заказ поставщику». Замена потребности аналогом может повлечь за собой изменения: Номенклатуры; Единиц измерения; Количества; Цены. Изменение номенклатуры возможно только с указанием номенклатуры, которая является аналогом к номенклатуре потребности. Пример: Номенклатура №1 её аналог Номенклатура №2; у Номенклатуры №2 аналог Номенклатура №3; При выборе аналога к Номенклатуре №1 возможно выбрать только Номенклатуру №2, т.е. ее прямые аналоги. Но в то же время Номенклатура №4 может являться аналогом для Номенклатуры №1 и Номенклатуры №3. Таким образом у одной номенклатуры может быть несколько аналогов. Изменение единицы измерения может произойти при смене номенклатуры. Изменение количества возможно в двух случаях: при изменении единиц измерения, тогда по коэффициенту будет пересчет количества. 60 при выборе аналога, если известно что, для покрытия одной единицы потребности в Номенклатуре №1 требуется две единицы в Номенклатуре №2. Изменение цены пользователем производится вручную, на следующих этапах т.к.: на этапе обеспечения работа ведется без учета стоимостных показателей; на этапе выбора поставщика цены указываются поставщиком, в АСУ МТО.TMS не хранятся; На этапе выполнения закупок, цена подтягивается по договору, выбранному в шапке документа «Заказ поставщику». 4.3.8. Категоризация запасов Создать предопределенные элементы справочника «Качество»: Востребованный ликвидный актив (ВЛ); Невостребованный ликвидный актив (НВЛ); Неликвидный актив (НЛ). Опционально ограничить работу с предопределенными значениями справочника «Качество» при обеспечении потребностей, для возможности одноразового обеспечения потребности за счет НВЛ и НЛ. Для установки значений качества номенклатуры «Невостребованный ликвидный актив» и «Неликвидный актив» документ «Корректировка качества товаров» перевести в управляемые формы. Данный документ позволит устанавливать предопределенные значения качества номенклатуры. Сделать возможным ввод корректировки на основании документа «Инвентаризация товаров на складах». Согласно Требованиям заказчика по учету неликвидов, полученному от Заказчика, разработать отчет, позволяющий отображать количество номенклатуры по партиям, которое находится на складах больше заданных промежутков. Расчёт количества по колонкам «Периоды» Номенклатура Перемешивать <30 дней 100 шт <60 дней <90 дней 50 шт <120 дней >120 дней 10 шт 61 Рукав сварки газовой 45 шт 100 шт По результатам проведения документа «Корректировка качества товаров» должны формироваться данные о качестве номенклатуры. Реализовать печатную форму, аналогичную «Акту технической аттестации МТР», предоставленной Заказчиком. Данные о качестве номенклатуры должны анализироваться и не попадать при обеспечении потребностей заявочной компании. Для этого необходимо разработать следующий механизм: Этап 1. Поступление от поставщика. При проведении документа «Поступление товаров и услуг» запасы по умолчанию становятся «ВЛ». Этап 2. В документы «Обеспечение заявочной компании» и «Распределение МТР» должны попадать запасы с признаком «ВЛ», «НВЛ». Этап 3. При формировании документов «Перемещение» запасы могут иметь качество «НЛ», «НВЛ», «ВЛ». В системе создать дополнительные признаки: «Ремонт», «Не требует ремонта», «Неремонтопригодное». ЦИП при проведении входного контроля обязан проставить признаки поступившим МТР. В случае присвоения признака «Неремонтопригодное», необходимо формировать документ «Требование накладная»; «Не требует ремонта» - присвоение качества «НВЛ»; «Ремонт» - качество может изменяться вручную. Этап 4. При проведении анализа хранения запасов, для изменения качества создать соответствующую обработку по изменению качества, доступную менеджеру по управлению запасами (+администратору). Обработка должна изменять качество по заданным параметрам: Качество, срок хранения, с указанием количества переводимых запасов с одного качества на другое. 4.3.9. Учет и выдача Спецодежды и СИЗ Внести в систему сведения по профилю для выдачи СО и СИЗ. Профиль должен содержать следующую информацию: Профиль Набор СО и СИЗ (Номенклатура, Количество) 62 Карточку сотрудника передавать из ЗИК в МТО (только ФИО, Должность, профиль, Антропометрические данные (уволен/работающий)). (Доработать ЗИК – сформировать документ «Требование на получение спецодежды и СИЗ»). Сформировать в подсистеме «Склад» новый документ – Выдача СО и СИЗ. Данный документ должен позволять осуществлять выдачу со склада СИЗ и СО непосредственно на сотрудника, используя данные карточки сотрудника из ЗИК. Где прогружается норматив, проставляется факт выданной СО и СИЗ. Сформировать отчёт по выданным СО и СИЗ. 4.3.10. Операции с основными средствами. Системой должны быть предусмотрены следующие операции с ОС для создания единого рабочего пространства для сотрудников. Перемещение Формирование ТТН. Учет/амортизация Основных средств ведется в Бухгалтерской системе, техническое сопровождение в системе MTO.TMS. Задача данной системы – оперативно оформлять перемещение. 4.4. Функциональные требования к блоку «Управление транспортом». 4.4.1. Основные требования. Система автоматизированного учета управления транспортом должна позволять решать следующие задачи: Планирование затрат на транспорт; Оперативное управление транспортом (включая заказ транспорта и контроль на маршруте); Учет фактических затрат на транспорт; Контроль соответствия объема, принимаемых у подрядчиков транспортных услуг, фактически оказанным услугам (включая контроль соответствия данных документов данным систем GlonassGPS); Нормирование и контроль выполнения нормативов использования транспорта; 63 Управление эффективностью транспортных подрядчиков; Ведение аналитической отчетности. Для выполнения данных задач система должна содержать следующую справочную информацию: Список контрагентов; Типы транспортных средств; Виды транспортных средств; Перечень транспорта допущенного к работе (с указанием гос. номеров); Нормативы использования транспорта (по скорости, по видам транспорта, по времени на погрузо-разгрузочные работы, на выполнение операций и т.д.) Список заказчиков транспорта (Пользователей); Виды грузов (вид, габаритные размеры, вес грузов и прочие технические характеристики); Производства (подразделения, филиалы); Месторождения; Кусты (место проведения работ); Скважины; КР (блоки тех. операций); Технические операции; 4.4.2. Ведение нормативов 4.4.2.1. Формирование нормативов При работе у Заказчика исторически сформировались определённые нормативы на перечень технологических операций, с учетом техники, по определенным видам работ. Нормативы могут формироваться: из требований заказчика; на основе анализа, проведенного внутри компании; исходя из сроков плана работ. 64 Система должна позволять планировать потребности в транспортных средствах, фиксировать нормативы на определенный перечень нормируемых показателей, проводить анализ по отклонению факта от плана и заданной нормы. Нормативы могут задаваться: по определённому контрагенту (заказчику); на продолжительность технологических операций, по определенным видам работ; на вид, модель и количество техники, с учетом на расход ГСМ (необходимо анализировать коэффициент плотности, для пересчета из литров в тонны), с учетом: Необходимо иметь возможность задавать и учитывать нормативы, как в разрезе заказчиков, так и в целом на анализируемый показатель, без отнесения на определенного заказчика. Если по анализируемым показателям, по определенному заказчику, есть нормативы, как заказчика, так и внутренние (учитываемые в компании), то большим приоритетом должен обладать норматив заведенный на заказчика. Необходима возможность введения кода по каждой технологической операции и дальнейшей идентификации тех. операций по коду в Систему. Необходимо фиксировать дату вступления (либо изменения) в силу норматива. С целью проведения сравнительного анализа плана, факта, и нормы необходимо фиксировать время действия каждого норматива, причем, при формировании нового норматива достаточно указать дату начала его действия. 4.4.3. Ведение лимитов 4.4.3.1. Формирование лимита Существует 3 уровня лимитов: Лимит № 1 - задается в соответствии со сформированным бизнес планом и контролируется с использованием справочника «заявочная кампания». Лимит № 2 формируется по определенному отчетному периоду (представляет из себя документ, сформированный исходя из уточненной 65 производственной программы с контролем превышения итоговых данных по Лимиту №1 за рассматриваемый отчетный период). В системе для функционирования бизнес-процесса планирования и контроля затрат, должна быть реализована возможность формирования Лимита № 3. Лимит № 3 формируется исходя из: лимита № 1; лимита № 2; заявки на ТС подрядчика; перечня ТС к использованию, исходя из плановой потребности. Лимит № 3 должен задаваться: в разрезе структурного подразделения; в суммовом выражении. Исходя из полученной суммы и сформированной потребности на определенный период (плановой) Система должна предоставлять возможность задать перечень техники к использованию, с детализацией по: подрядчику; периоду предоставления ТС; виду ТС; модели ТС; марке ТС; режиму работы ТС; количеству транспорта. Необходимо фиксировать дату вступления в силу лимита. 4.4.3.2. Автоматический контроль лимитов в сумме и в транспорте При выполнении работ, на определенный период, закладываются ограничения по затратам в транспорте, исходя из установленного ограничения затрат по сумме на рассматриваемый период. Система должна позволять: 66 выводить предупреждения о возможности превышения лимита, за счет превышения режима работы (как следствие затрат) за анализируемый период. автоматически устанавливать признак выхода за рамки лимита на документы системы. Признак выхода за рамки лимита автоматически должен устанавливаться при превышении: установленной суммы; использования транспорта, за счет внесения внеплановых заявок на ТС. Реализовать в системе возможность формирования служебной записки по каждому сверхлимитному документу «Рейс». В дальнейшем, при учете выполненных подрядчиком работ, ответственный за пост-согласование сверхлимитных затрат сотрудник, может на основании служебной записки разрешить пустить документ «Рейс» в дальнейшую обработку. Под дальнейшей обработкой понимается сравнение информации в документе «Рейс» с данными из реестра подрядчика, их утверждение и распределение затрат по входящим счет фактурам, содержащим данные рассматриваемого документа. Система должна предоставлять возможность e-mail оповещения ответственных сотрудников при расходовании 80% лимита. Так же необходима повторная отправка электронного оповещения, при полном исчерпании лимита. 4.4.3.3. Прогнозирование выхода за рамки лимита, сверхрежим В Системе необходимо разработать механизм прогнозирования выхода структурного подразделения за рамки лимита. Для этого нужно реализовать регламентный анализ выхода перечня контролируемых производств за рамки планового объема работ (в машино-часах). Анализ должен происходить посредством получения планового значения режима, по каждому ТС заданному на период контроля и его фактическому значению (превышению) – сверхрежим. 67 Период контроля должен настраиваться опционально, по желанию пользователя. В качестве значения по умолчанию предлагается установить значение равное одному дню. В случае предупреждение возникновения в системе, с сверхрежима последующей выводить соответствующее возможностью открытия расшифровки сверхрежима, в виде аналитического отчета, с детализацией по: типу ТС; виду ТС; гос. номеру ТС; отклонению от планового объема; количеству рабочих дней, которые можно отработать с полученным темпом расхода ресурсов; остатку лимита в деньгах; остатку лимита в технике. Так же реализовать возможность оповещения, о факте выявления сверхрежима, с приложением файла расшифровки сверхрежима, при помощи электронной почты. В соответствующих настройках системы учитывать: период контроля; перечень получателей; период рассылки; текст письма; Перечень получателей – список почтовых адресов для рассылки писем с информированием о сверхрежиме. Период контроля – период, в соответствии с которым будет происходить регламентный анализ сверхрежима, значение по умолчанию – день. Период рассылки - период, в соответствии с которым будет происходить рассылка электронных писем об информировании сверхрежима. Текст письма – текстовое поле, для возможности задания расшифровки письма. 68 4.4.3.4. Автоматическое заполнение документа «Лимит в технике» Документ «Лимит в технике», отражающий перечень транспортных средств, представленных подрядчиком по отправленной ему ранее заявке на ТС. Этот документ доступен для ручного заполнения перечня видов ТС. Необходимо реализовать возможность автоматического заполнения документа «Лимит в технике» из электронного файла в формате .xls, утвержденной формы. Разработать печатные формы документа «Лимит в технике». 4.4.4. Планирование потребностей в технике 4.4.4.1. Ввод потребности в технике Существует годовой бизнес план, с детализацией по объекту работ; подразделению; планируемому временному интервалу. Работы из годового плана распределяются на под периоды (ОНР – месяц, ИБ – в соответствии с периодом этапа проекта). Потребности формируются исходя из годового плана с учетом подпериодов планирования. Существует 2 вида потребности: Плановая потребность – формируется на длительный период - срок этапа проекта, ОНР - месяц) Оперативная потребность – формируется на короткий период (день) для непосредственного запуска в работу, с учетом плановой потребности на рассматриваемый период. При формировании оперативной потребности используются транспортные средства исходя из установленного Лимита №3 на рассматриваемый период. Система должна предоставлять механизм, позволяющий формировать потребности: с указанием одного из видов потребности - необходимо для работы некоторых механизмов системы, в том числе, определения типа требуемого транспортного средства, планирования затрат, получения 69 аналитики в данном разрезе. Выбирается пользователем из указанных возможных вариантов: o потребность в перевозке грузов; o потребность в перевозке сотрудников; o потребность в выполнении работ. Так как в зависимости от каждого из перечисленных значений видов потребности будет зависеть результат работы определенных механизмов, то указанный список значений не может редактироваться и расширяться пользователями с любым уровнем доступа. с указанием периода (под период годового плана) планирования; с указанием варианта задания потребности: o плановая; o оперативная. с возможностью ведения статусов потребности - необходимо для определения состояния обработки документа в любой момент времени, и возможности разрешения/блокирования определённых операций в зависимости от значения статуса. o новый; o к выполнению; o выполняется; o выполнено. с указанием приоритета – необходимо для классификации потребностей и соответствующей обработки каждой из них: o низкий – не срочная потребность; o нормальный – потребность внесенная в плановом режиме; o высокий – аварийная потребность, внесенная вне плана. с указанием параметров маршрута: o с указанием отправителя, отправителем может быть цех; бригада; 70 физическое лицо. o с указанием места отправления, местом отправления может быть конкретный географический адрес отправителя; o с указанием получателя, затраты на передвижение транспорта между объектами относятся на получателя, получателем может быть: цех; бригада; физическое лицо. o с указанием места прибытия, местом прибытия может быть конкретный географический адрес получателя o с указанием контактных лиц отправителя и получателя; o с указанием временных отрезков отправления и получения. в случае возникновения потребности в перевозке грузов, с указанием: o груза, грузом может считаться: перевозимое оборудование; сопутствующие производству потребности: нефть; вода; ГСМ. o вида упаковки груза; o классификации груза по ТНВЭД; o класса опасности груза; o количества мест груза; o веса нетто груза; o веса брутто груза; o длины груза; o ширины груза; o высоты груза; 71 o объема груза; o количества загрузочных метров груза; o характера груза; o способа определения массы; o товарного состава груза, с возможностью: указания документа по грузу; указания конкретной номенклатурной позиции, являющейся частью груза; указания характеристики номенклатурной позиции; указания серии номенклатурной позиции; указания ед. изм. номенклатурной позиции; указания количества номенклатурных позиций; указаний цены номенклатурной позиции; указания валюты цены; автоматического параметров, при заполнения изначальном вышеуказанных занесении их в соответствующие аналитические параметры груза; в случае возникновения потребности в перевозке сотрудников, с указанием: o количества сотрудников; o перечня сотрудников, при необходимости. в случае возникновения потребности в выполнении работ, с указанием: o вида работы; o технологической операции, по выбранному виду работ; o планируемой продолжительности технологической операции; o продолжительности технологической операции по нормативу, с учетом параметров объекта работ (например, глубина скважины). с указанием перечня детализацией по: требуемых транспортных средств, с 72 o виду транспортного средства; o модели транспортного средства; o марке транспортного средства; o количеству необходимых транспортных средств. АСУ TMS должна позволять потребности по подразделениям при формировании плановой ЦФО, устанавливать перечень техники к использованию на рассматриваемый период, с указанием: подрядчика; периода предоставления ТС; вида ТС (Тип ТС); модели ТС (Вида ТС); количества видов ТС определенного типа; марки ТС, при необходимости; режима работы ТС; количества дней работы ТС Реализовать с автоматический расчет сумм затрат по выбранному перечню ТС. 4.4.4.2. Согласование потребности. Чтобы запустить введенную потребность в дальнейшую обработку, необходимо фиксировать соответствие новой потребности утвержденному на текущий период Лимиту № 3:в случае внесения в рамках Лимита№ 3, потребность идет в работу. В случае внесения внеплановых затратили при превышении лимита, задание на работу, сформированное на основании потребности должно иметь признак «Сверхлимитный», с возможностью описания причины возникновения. Признак «Сверхлимитный» влияет на дальнейшее согласование работ по введенной потребности (утверждение выполненных работ и передача на обработку в бухгалтерию), потребность в любом случае должна идти в работу. 4.4.4.3. Согласование оперативной сверхлимитной потребности 73 На основании наличия признака «Сверхлимитный» происходит пост согласование, ответственными лицами, выхода затрат за рамки лимита, по уже пущенным в работу потребностям. Пост согласование должно происходить с возможностью утверждения отработанных потребностей: на основании вложенного в АСУ TMS отсканированного документа, объясняющего причину внесения сверхлимитной потребности (служебная записка, СЗ); на основании описания, объясняющего причину внесения сверхлимитной потребности. Если процесс согласования пост фактом не завершен, либо не инициирован тогда: работы, выполненные по соответствующей потребности, не будут попадать в список утвержденных работ и соответственно не будут доступны для дальнейшей обработки в бухгалтерии; задание на работу по соответствующей сверхлимитной потребности не будет закрыто (не установится в статус «Выполнено»). Во второй очереди реализации проекта рассматривается возможность формирования служебной записки в системе, по установленному образцу, с привязкой к документу согласования 4.4.4.4. Формирование печатных форм Необходимо иметь возможность визуального отображения и печати на бумажный носитель печатной формы листа согласования. 4.4.4.5. Работа с долгосрочными потребностями в технике При формировании годовой потребности в транспортных услугах при помощи обработки «Ввод и согласование потребностей» на каждый период определяется перечень техники, в соответствии с суммой выделенной на этот период. АСУ МТО.TMS должна предоставлять возможность, при долгосрочном планировании потребностей транспортного характера, формировать перечень 74 техники на определенный период, в соответствии с суммой выделенной на этот период. Реализовать данную возможность посредством документа «Потребность в технике», с указанием: потребности в транспортной услуге; наименование транспортной услуги потребности; тип ТС; вид ТС; количество ТС; режим работ ТС; количество дней использования ТС; количество машино-часов использования ТС; тариф; сумма затрат на ТС. При корректировке годовых потребностей в транспортных услугах, необходимо иметь возможность корректировки ранее созданного при планировании документа «Потребность в технике», с перечисленным перечнем ТС. Иметь возможность сохранять в системе первоначально введенный документ и его скорректированные версии, причем последний скорректированный вариант должен нести в себе актуальные данные на анализируемый период, прошлые же версии должны быть доступны только для аналитики. Аналитика по корректировкам годовых потребностей должна отображаться в виде отчетной формы (необходимо разработать). Заложить печатную форму документа «Потребность в технике». Перечень аналитики, который необходим в отчете: Транспортная потребность; Транспортная номенклатура; Сумма лимита, на период формирования документа; Данные по ТС, заложенные под определенную сумму лимита: Вид ТС; 75 Количество ТС; Режим; Количество дней; Количество часов; Тариф; Сумма; 4.4.4.6. Учет пропусков В процессе работы Заказчик предоставляет требования к наличию пропусков на объектах работ. Система должна позволять формировать и вести учет пропуска, как по подрядчикам, так и по собственному парку транспортных средств. Учет должен быть реализован: по Заказчику работ; по подрядчикам, в случае наемных ТС; на транспортные средства; на водителей; на месторождения; по сроку действия. Данные по наличию пропусков должны быть доступны к анализу в виде отчетной формы (необходимо разработать). 4.4.5. История работы с подрядчиком При выполнении работ случаются различные отклонения от условий, заложенных в договоре с подрядчиком, в том числе и по причине поломки транспортных средств. Система должна предоставлять возможность хранения истории по всем работающим\работавшим в Филиале подрядчикам и его транспортным средствам, с детализацией по: типу ТС; виду ТС; гос. номеру ТС; 76 подрядчику, предоставившему ТС, при использовании наемного транспорта; периодам работы ТС; местам работы ТС (производства); заданиям, выполненным ТС; актам отклонений; расходу ГСМ, при учете ГСМ; тарификации; объему работ с подрядчиком в машино-часах; сумме затрат на подрядчика; транспортным средствам, входящим в черный список ТС; судебной перепиской. Акты отклонения должны быть заведены на анализируемое ТС, с указанием причины актирования (сход с линии, невыход и т.п.). В случае заведения акта схода с линии, с указанием предопределенного значения «Поломка» учитывать эту информацию, как статистику по поломкам ТС. Судебная переписку хранить в системе путем прикрепления файла переписки к элементу справочника «Контрагенты». 4.4.6. Формирование заявки подрядчику 4.4.6.1. Консолидация заданий на работу Полученные задания на работу, в определенное время , с целью эффективного использования транспорта и сокращения затрат на транспортные услуги консолидируются по контрольным параметрам: объект работ; технологическая операция; сроки работ; необходимая техника. Система должна предоставлять удобный механизм для консолидации заданий на работу, в виде специального рабочего места, позволяющего на сформировать из нескольких потребностей сформировать заявку подрядчику. 77 Рабочее место должно позволять: анализировать по: o срокам выполнения работ (планируемое время начала, окончания работ); o местам отправления, прибытия (объектам работ); o видам и моделям транспортных средств; o при перевозке грузов: массе груза; объему груза; количеству мест; количеству загрузочных метров; грузоподъемности транспортного средства; объему транспортного средства; количеству мест транспортного средства; количеству загрузочных мест транспортного средств. o при перевозке сотрудников: количеству перевозимых сотрудников; количеству посадочных мест транспортного средства. o при выполнении работ: виду работ; технологическим операциям, определенного вида работ. формировать рейс на выполнение заданий: o с учетом типа рейса на выполнение заданий: развоз - от одного места отправления транспортное средство разъезжает по различным местам прибытия; сборный – компактность расположения мест отправления и прибытия; последовательный – место прибытия одного задания на работу должно быть местом отправления другого задания на работу, либо находится недалеко; 78 произвольный – произвольное формирование рейса на выполнение заданий. o с указанием: вида транспортного средства; модели транспортного средства; марки транспортного средства; транспортного средства, при известности. Транспортное средство, как собственное, так и наемное может быть известно, если оно уже находится в нашем распоряжении(имеется в собственном парке или ранее было нанято у подрядчика) и готово к работе; водителя; организации; исполнителя, если он известен. o с настройкой фильтрации транспортных средств по параметрам, например: вместимости; доступности мест отправления и прибытия; допустимым типам кузовов; температурному режиму; классу опасности. В результате необходимо получить сформированный Рейс на выполнение заданий: с указанием статуса рейса на выполнение работ - необходимо для определения состояния обработки документа в любой момент времени, и возможности разрешения/блокирования определённых операций в зависимости от значения статуса: o новый; o к выполнению; o выполняется; o выполнено. 79 в разрезе организаций – необходимо для отнесения рейса к конкретной организации; с указанием исполнителя, исполнителем может быть как подрядчик, если он определен (используется наемный транспорт), так и собственная организация (при использовании собственного транспорта); с указанием вида транспортного средства; с указанием модели транспортного средства; с указанием марки транспортного средства; с указанием транспортного средства, если известно. Транспортное средство, как собственное, так и наемное может быть известно, если оно уже находится в нашем распоряжении(имеется в собственном парке или ранее было нанято у подрядчика) и готово к работе; с указанием водителя, если известен; с указанием группы тарифов; с указанием количества километров; с указанием количества часов, с возможностью классификации по виду, например: o полная отработка – 100% ставки машино-часа; o технологический простой, технологическое дежурство – 50% ставки машино-часа; o консервация – 30% ставки машино-часа; с указанием стоимости рейса на выполнение заданий; с указанием коэффициента загрузки транспортного средства; с указанием, при перевозке груза: o общего веса грузов по заданиям; o общего объема грузов по заданиям; o общего количества мест по заданиям; o общего количества загрузочных метров по заданиям. с указанием, при перевозке сотрудников: 80 o общего количества перевозимых сотрудников. с указанием, при выполнении работ: o видов выполняемых работ; o технологических операций, по выполняемым работам. с указанием перечня заданий на работу, вошедших в рейс на выполнение заданий, с детализацией по: o заданию на работу; o варианту задания на работу: перевозка грузов; перевозка сотрудников; выполнение работ. o номеру звена задания на работу; o месту отправления; o месту прибытия; o расстоянию между местом отправления и прибытия, с возможностью автоматического расчета; с указанием маршрута, детализируется по: o адресу – адрес места отправления или места получения; o операции, доступные значения: прибытие; отправление; контрольная точка. o времени прибытия, плановое; o времени отправления, плановое; o времени работ – из расчета времени прибытия и отправления; o заданию на работу; o номеру звена задания на работу; o контрольной точки – при необходимости фиксирования прохождения транспорта по адресу контрольной точки; o расстояние – расстояние между адресами маршрута, с возможностью автоматического расчета; 81 с указанием дополнительных работ. Система должна предоставлять механизм, позволяющий при формировании Рейса на выполнение задания на работу, с определенным маршрутом, автоматически рассчитывать длину маршрута по каждой введенной последовательности адресов и отображать последовательность выполнения маршрута на ЭГК. При создании рейса на основании заданий на работу, все соответствующие данные должны автоматически переноситься (из задания на работу в рейс), для исключения двойного ввода данных. 4.4.6.2. Формирование заявки на предоставление ТС подрядчику В системе должна быть возможность формирования заявки на предоставление ТС. Заявка может формироваться как на длительный срок, так и разовая, в зависимости от запланированного периода работы ТС. В заявке должна содержаться информация по: организации, от которой подается заявка; подрядчику, которому подается заявка; договору с подрядчиком; адрес места подачи транспортного средства(с указанием месторождения, куста, скважины); дата, время подачи транспортного средства; адрес места завершения работы транспортного средства (необходимо указывать при перевозке груза), при известности; дата, время окончания работы транспортного средства; перечень необходимых моделей ТС; количества ТС по каждой модели; 4.4.6.3. Формирование печатных форм АСУ TMS должна позволять формировать для визуального отображения и возможности печати: при использовании собственной печатную форму «Путевой лист»; техники, унифицированную 82 4.4.6.4. Рабочее место: «Контроль прохождения рейсов» В рамках второй очереди работ в АСУ МТО.TMS произвести доработку существующего функционала рабочего места «Контроль прохождения рейсов» (РМ). Реализовать опциональную возможность выводить значение лимита: в деньгах; в часах по виду ТС; Вывод значения в деньгах и в часах необходимо выводить как плановое значение суммы на рабочий период по каждому виду ТС, так и остаток на анализируемый период. Значение остатка обновлять при выпуске нового ТС в рейс, расчет должен происходить на основе плановых и фактических затрат, полученных на текущий момент по каждому виду ТС (плановое значение – фактические затраты). Реализовать возможность оперативного получения всей информации, предоставляемой механизмом «Доступность и контроль ТС». Система должна предоставлять возможность оперативно задавать контрольные точки по рейсам, с последующим анализом прохождения контрольных точек. 4.4.6.5. Пакетная печать путевых листов При планировании работы собственных транспортных средств нужно учитывать возможность непрерывного задействования ТС на производстве. При подобной работе транспортные средства могут находится на объекте работ длительный период. Для обеспечения учета и контроля работы транспортных средств при длительном использовании их на объектах работ Система должна позволять выводить на печать путевые листы: на каждый день заданного периода; на заданный перечень ТС; В путевых листах необходимо заполнение ключевых полей (организация, автомобиль, режим работы) и возможность заполнения бригад; 83 При массовой печати Система должна позволять задавать период ограничения, за который может быть реализована пакетная печать путевых листов. 4.4.6.6. Замена ТС В процессе выполнения работ случаются поломки транспортных средств. Так же возможно попадание на объект работ транспорта, не удовлетворяющего необходимым показателям эффективности. В подобных случаях необходимо оперативно произвести замену как собственного, так и наемного транспорта. Система должна позволять как на основании документа «Акт отклонения» с видом «сход с линии» так и без привязки к определенному документу, произвести замену ТС, с учетом: ТС, подлежащего замене; ТС, пришедшее на замену; период замены ТС; наследования признака вхождения в лимит, либо выхода за рамки лимита; подрядчика, предоставившего заменяемое ТС. При замене ТС автоматически выводить из списка доступных на период ТС, технику подлежащую замене и вносить технику, пришедшую на замену. 4.4.6.7. Формирование приложения к талону Заказчика Для реализации возможности визуального отображения документа «Приложение к талону Заказчика», подключить соответствующую печатную форму к документу «Рейс». В печатной форме из электронного документа автоматически заполнять следующие поля: ФИО водителя; № путевого листа; марка ТС; гос. №; производство; 84 режим работы ТС. 4.4.6.8. Расчет ВГХ при выпуске ТС в рейс При необходимости выполнения перевозки груза, сотрудник подбирает оптимальное ТС, с точки зрения соблюдения весогабаритных характеристик. Система должна предоставлять механизм сравнения ВГХ транспортного средства и ВГХ планируемого к перевозке груза. В случае превышения одного из параметров ВГХ груза по отношению к ВГХ выбранного транспорта, выдавать соответствующее предупреждение пользователю системы. 4.4.7. Получение и обработка информации при помощи БСМТС 4.4.7.1. Интеграция с поставщиками услуг Датчики, установленные как на транспорт подрядчика, так и на собственные ТС отправляют данные, на сервера сбора данных соответствующих поставщиков услуг спутникового мониторинга. При разработке системы и перед запуском её в опытную эксплуатацию требуется произвести интеграцию для получения данных датчиков БСМТС. 4.4.7.2. Автоматическое получение координат местонахождения ТС Система должна иметь возможность получать в режиме онлайн информацию о местонахождении транспортных средств, имеющих датчики БСМТС соответствующих поставщиков услуг. Данная информация в дальнейшем будет обрабатываться системой для получения аналитической информации. 4.4.7.3. Автоматическое фиксирование прохождения контрольных точек На каждом из объектов работ существуют перечень адресов, на которые отправляются, и работают транспортные средства. Для контроля прохождения данного перечня адресов фиксируются ключевые географические адреса (контрольные точки). Система должна позволять создавать контрольные точки в одноименном справочнике системы. Предоставлять возможность обрабатывать созданные контрольные точки, а именно: задавать контрольные точки для прохождения; 85 задавать запрещенные контрольные точки для прохождения; автоматически записывать в документ «Рейс» прохождение заранее определенной контрольной точки; сравнивать фактическое прохождение контрольных точек с плановыми значениями; отбирать транспортные средства и контрольные точки; создавать и читать заметки по работе каждого ТС на контрольной точке. Создание географических контрольных координат точек (широты, должно происходить долготы) и задания с указанием произвольного наименования. Необходимо иметь возможность задавать контрольные точки как при планировании работы ТС, так и при выпуске ТС в рейс. Запрещенные контрольные точки должны иметь период, на который данная точка считается запрещенной. Предоставлять возможность задавать запрещенные контрольные точки как при планировании работы ТС, так и при выпуске ТС в рейс. Прохождение заранее определенной контрольной точки должно фиксироваться, с детализацией по: времени прибытия на точку; времени убытия с точки; продолжительности нахождения на точке. Отбор должен происходить из общего перечня ТС предоставленных на период, для анализа прохождения контрольных точек отобранными ТС. Так же предусмотреть отбор по контрольным точкам, с выводом всех ТС, прошедших отобранную контрольную точку, за анализируемый период, с возможностью визуализации на ЭГК. 4.4.7.4. Автоматический расчет времени присутствия ТС на точке 86 Система должна позволять автоматически рассчитывать время пребывания транспортного средства на контрольной точке. Все контрольные точки должны быть определенны в системе. Это позволит вести более прозрачный учет по времени, за счет еще одного источника поступления информации, не зависящего от человеческого фактора. 4.4.7.5. Анализ данных по ГСМ Транспорт, находящийся на объекте работ потребляет ГСМ. С целью более прозрачного учета движения ГСМ должна позволять фиксировать и выводить следующую информацию: факты заправки ГСМ в транспортное средство. количество фактов заправки за анализируемый период; количество фактов слива за анализируемый период; остаток топлива в баке на анализируемый период; средний расход ГСМ, за анализируемый период; нормативные значения по расходу ГСМ. По полученным и слитым объемам ГСМ фиксировать: время факта получения\слива топлива; географический адрес, в котором было движение топлива; приемник топлива. Данные должны предоставляться как посредством БСМТС, так и посредством расчета данных собранных в системе, путем занесения их пользователями. Для того чтобы получать информацию посредством БСМТС, необходимо иметь соответствующие установленные датчики на контролируемых ТС. На основе полученных данных должен формироваться отчет «Движение ГСМ», с указанием нового источника поступления данных – «БСМТС». 4.4.7.6. Анализ данных по работе двигателя Для более детальной аналитики работы транспортного средства и контроля его работы, реализовать возможность получения информации (при наличии соответствующих установленных датчиков БСМТС) о работе двигателя: время начала работы; 87 время окончания работы; факт движения ТС; состояние работы двигателя в режиме онлайн (работает/не работает). 4.4.7.7. Доступность и контроль ТС При производстве, на объекте работ находится большое количество техники. Сотрудникам Филиала необходимо иметь аналитику по каждой транспортной единице, находящейся на производстве. Это нужно для того чтобы выполнять 2 основные задачи для эффективного управления транспортными ресурсами: Выпуск ТС в рейс. Мониторинг работы ТС. Аналитика и управление транспортных средств должна вестись в разрезе производств организаций. 4.4.8. Фиксирование фактического использования техники 4.4.8.1. Оперативное управление рейсом на выполнение заданий В АСУ TMS необходимо специальное рабочее место по оперативному вводу точек маршрута в заведенном рейсе на выполнение заданий. Рабочее место должно позволять: оперативно вводить новые адреса маршрута; рассчитывать протяженность цепочек адресов в маршруте; учитывать время прибытия к каждому адресу цепочки маршрута; время работы по каждому адресу цепочки маршрута. Во второй очереди реализации проекта: позволять строить оптимальный маршрут движения ТС; предлагать ТС находящееся в непосредственной близости от объекта, с учетом его плана работ. 4.4.8.2. Регистрация отклонения от условий, заключенных в контракте с подрядчиком (актирование) 88 При факте отклонения выполнения работ (сход с линии, невыход, простой бригады и т.п.) подрядчиком от условий, описанных в договоре с ним, запускается процесс актирования. Во второй очереди реализации проекта в системе необходимо фиксировать условия контракта с подрядчиком, в том числе по актированию с последующим применением штрафных санкций. АСУ TMS должна позволять вводить акт по конкретному выполнению работ, с возможностью фиксирования информации по: подрядчику; месту возникновения\отнесения акта: при простое бригад: дате, времени возникновения отклонения; дате, времени окончания отклонения; количество часов простоя; номеру путевого листа; транспортному средству подрядчика: виду работ и технологической операции, при которой возникло отклонение; виду отклонения, из предлагаемого, утвержденного перечня. Перечень может меняться и дополняться, например. описанию отклонения; третьим лицам, принявшим участие в формировании акта. Система должна позволять привязывать сформированный акт к конкретному выполнению работ (путевому листу), для дальнейшего учета отклонений при сверке данных по отработанным позициям с подрядчиком. 4.4.8.3. Регистрация факта выполнения работ (отработка заданий) По факту выполнения работ ответственным лицом фиксируется работы: по каждому транспортному средству; каждой запланированной точке маршрута. 89 В АСУ TMS необходимо специальное рабочее место по контролю прохождения запланированных точек ранее заданному маршруту. Рабочее место должно позволять по выделенному из перечня рейсу видеть запланированные точки маршрута, отмечать прохождение произвольных точек маршрута. При отметке прохождения каждой точки маршрута, Рейс на выполнение заданий должен считаться выполненным. По факту выполнения работ, необходимо зафиксировать Выполнение рейса (отработка): в разрезе организаций; с указанием исполнителя, исполнителем может быть как подрядчик, если использовался наемный транспорт, так и собственная организация, при использовании собственного транспорта; с указанием вида транспортного средства; с указанием модели транспортного средства; с указанием транспортного средства; с указанием водителя; с указанием группы тарифов работы с подрядчиком; с указанием количества пройденных километров; с указанием количества отработанных часов, с возможностью классификации по виду, например: o полная отработка – 100% ставки машино-часа; o технологический простой, технологическое дежурство – 50% ставки машино-часа; o консервация – 30% ставки машино-часа; с указанием суммы затрат; с указанием, при перевозке груза: o общего веса грузов по заданиям; o общего объема грузов по заданиям; o общего количества мест по заданиям; 90 o общего количества загрузочных метров по заданиям. с указанием, при перевозке сотрудников: o общего количества перевезенных сотрудников. с указанием, при выполнении работ: с указанием перечня заданий на работу, вошедших в рейс на выполнение заданий, с детализацией по: с указанием маршрута, детализируется по: o адресу – адрес места отправления или места получения; o операции, доступные значения: прибытие; отправление; контрольная точка; завершение. o времени прибытия, фактическое; o времени отправления, фактическое; o времени работ – из расчета времени прибытия и отправления; o заданию на работу; o номеру звена задания на работу; o контрольной точки – при фиксировании прохождения транспорта по адресу контрольной точки; o расстояние – расстояние между адресами маршрута. По регистрации выполненных работ, с занесением фактических показателей выполнения рейса, необходимо иметь возможность сравнивать фактические данные с плановыми по контрольным показателям, например: прохождение цепочек маршрута; время прибытия на место работ; время работы; время отбытия; перечень используемой техники, исходя из Лимита № 3. 4.4.8.4. Контроль работы ТС по производствам 91 Использование функционала рабочего места «Контроль прохождения рейсов» на каждом из производств позволит выпускать транспортные средства в рейс: с получением для прохождения плановых точек маршрута; с оперативным заданием новых точек маршрута Пользователь может контролировать прохождение точек маршрута, следующим образом: фиксировать прохождения точки маршрута; фиксировать отклонения от маршрута. Отклонение от маршрута должно фиксироваться путем введения новой контрольной точки в запланированный маршрут рейса. В АСУ MTO.TMS реализовать возможность контроля выпуска ТС по производствам. Анализируя производства в режиме онлайн, предлагается выводить следующую информацию: наименование производства; плановый лимит на производство (в деньгах и в машино-часах по каждому виду ТС); остаток лимита на производство (в деньгах и в машино-часах по каждому виду ТС); ФИО ответственного за выпуск и контроль ТС в рейсах; перечень задействованной техники; плановые точки маршрута по рейсам; оперативно введенные точки маршрута по рейсам; пройденные точки маршрута по рейсам; отклонения от плановых точек маршрута рейса. Оперативно введенные точки маршрута – точки, введенные в маршрут определенного ТС, при помощи рабочего места «Контроль прохождения рейсов». Оперативный ввод точек маршрута может быть реализован как отметка о 92 прохождении плановой точки, либо как ввод незапланированной к прохождению географической точки. 4.4.8.5. Статусы в «Акте отклонения» При выполнении работ случаются отклонения от условий договора, заключенного с подрядчиком. В таком случае зарегистрировать отклонение в виде Акта, для последующего предъявления Заказчику. В случае если в условиях договора прописаны дополнительные уточнения по оформлению акта. Например, поломка ТС в виде акта регистрируется в случае непредставления замены в течение оговоренных договором часов. Для внутренней статистики внутри компании учитывать факт поломки ТС, даже в случае замены подрядчиком в оговоренные договором рамки часов. В АСУ MTO.TMS в рамках первой очереди реализован документ «Акт отклонения». С целью учета факта поломок, без регистрации официального акта, ввести новые признаки документа «Акт отклонения»: официальный; внутренний. Признак «Официальный» устанавливается пользователем вручную в документе «Акт отклонения», в случае официального оформления и представления претензий подрядчику. Признак «Внутренний» устанавливается пользователем вручную в документе «Акт отклонения», для внутреннего учета фактов отклонения, при выполнении работ. Оформления и представления претензий подрядчику не выполняется. 4.4.8.6. Распределение затрат При фиксировании фактического использования техники распределять затраты на соответствующих потребителей транспортных ресурсов. В АСУ МТО.TMS учитывать различные способы распределения затрат на объект отнесения: пропорционально весу; пропорционально грузовой единице; 93 пропорционально пробегу; пропорционально времени нахождения на объекте работ; равномерно количеству объектов отнесения затрат; Пропорционально весу – распределение затрат на объекты отнесения, в соотношении с их вкладом груза в общий вес перевозки. Пропорционально грузовой единице – распределение затрат, в соотношении с количеством грузовых единиц объектов отнесения в общем количестве грузовых единиц в рейсе. Пропорционально пробегу – распределение затрат в соотношении с пробегом, предназначенным для конкретного объекта отнесения в общем расстоянии пробега рейса. Пропорционально времени нахождения на объекте работ – распределение затрат, в соотношении со временем нахождения ТС на месте работ конкретного объекта отнесения затрат, к общему количеству затраченного времени в рейсе. Равномерно количеству объектов отнесения затрат – распределение затрат равномерно на каждого участвовавшего в рейсе объекта отнесения затрат. Под объектами отнесения затрат в Системе должны быть предусмотрены: проект\этап проекта; месторождение; куст; скважина; подразделение\производство; бригада; вид работы; тех. операция. Сумма затрат, подлежащая распределению, определена в счет фактуре, представленной подрядчиком. Распределение затрат в системе должно происходить по каждой утвержденной входящей счет фактуре. Счет фактура считается утвержденной, при принятии объемов работ, по ней. Входящие счет фактуры регистрируются при помощи документа «Подтверждение отработки». 94 4.4.8.7. Выполненные работы по бригадам Разработать отчётную форму, по распределению объема выполненных работ и затрат на выполнение данных работ по бригадам (машино-часы по бригадам, сумма затрат по бригадам). Бригады должны объединяться в производства\подразделения. Подразделения должен объединяться в организации. Таким образом мы увидим затраты как в материальном выражении так и в объемах по каждой из возможных структурных единиц компании, с учетом ее иерархии. Так же отображать по каждой бригаде простой техники и его соотношение ко всем отработанным часам, с возможностью иерархической группировки бригад по подразделению, организации. Перечень аналитики, для вывода в печатную форму: общий объем работ по рейсу; общий объем затрат по рейсу; объем работ на производственную единицу (ПЕ); объем затрат на ПЕ; количество часов простоя техники на ПЕ; соотношение часов простоя к общему объему работ ПЕ. Производственной единицей должна быть бригада, с группировкой по подразделениям\производствам. 4.4.8.8. Фиксирование и анализ поломок транспортных средств В процессе выполнения работ может произойти поломка транспортных средств, как собственных, так и предоставленных подрядчиком. Каждая подобная поломка несет в себе задержку в производстве, как следствие упущенную выгоду и дополнительные затраты. Для профилактики поломок собственных ТС и предотвращения попадания в парк предоставленной в рамках лимита от подрядчика техники часто ломающихся ТС, АСУ МТО.TMS должна позволять: фиксировать информацию о поломках транспортных средств (посредством акта схода с линии); отображать часто ломающиеся ТС в черном списке; 95 рассчитывать штрафные санкции, предусмотренные при факте поломки ТС; выводить предупреждение при добавлении в документ «Лимит в технике» проблемных ТС; Выводить черный список ТС в виде отчетной формы, с указанием: o ТС; o контрагента, предоставившего ТС; o количество фактов поломок, за анализируемый период; o актов заведенных на ТС, за анализируемый период. 4.4.9. Согласование с подрядчиком объема выполненных работ 4.4.9.1. Формирование реестра подрядчика По факту выполнения работ, подрядчиком с определенной периодичностью (подекадно) высылаются данные по выполненным работам. предоставление подрядчику доступа к заведенным по нему данным, с возможностью согласования, за выбранный период по выполненным им работам через личный кабинет на сайте компании; автоматическая периодическая (по заданному времени) рассылка зарегистрированных по определенному подрядчику работ по электронной почте. В Системе, по полученным от подрядчика данным, необходимо формировать реестр выполненных работ, содержащий следующую информацию: подрядчик, выполнивший работы; договор с подрядчиком; водитель, выполнявший работы; номер заявки на предоставление транспортного средства; наименование производства; номер и дата заявки на предоставление транспортного средства; номер и дата путевого листа; маршрут, место выполнения работ; вид транспортного средства, выполнявшего работы; 96 модель транспортного средства, выполнявшего работы; марка транспортного средства (тип подвижного состава); гос. номер транспортного средства; оплачиваемое время, с классификацией по виду часов, например: o тех. отстой\дежурство; o полная отработка; o консервация. стоимость 1 м\ч; сумма. данные по счету-фактуре. В Системе должна быть возможность формировать данные по выполненным работам подрядчиком, но не подтвержденным соответствующими документами, для отнесения затрат на текущий период (справка по начислениям). 4.4.9.2. Сравнение данных подрядчика с данными в системе После принятия реестра работ, предоставленных подрядчиком, происходит процесс автоматического сравнения данных из реестра с данными, зарегистрированными в Компании. При выявлении отклонений происходит процесс выяснения причин. Фиксируются результаты обработки по отклоненным позициям. Необходимо реализовать возможность автоматического сравнения данных подрядчика с данными, зарегистрированными в АСУ TMS, с выявлением отклонений. По результату сравнения необходимо получить: перечень совпавших работ; перечень отклонений. По перечню отклонений должно происходить выяснение причин отклонений с заказчиком, с возможностью фиксирования выясненных причин и договоренностей к конкретным отклоненным позициям. 4.4.9.3. Формирование справки распределения по утвержденным работам 97 По результату сравнения данных и выяснения причин отклонений должен быть предоставлен перечень работ, готовых к утверждению. Данный перечень работ подлежит дальнейшей обработке в бухгалтерии. Система должна позволять сформировать Справку распределение на основании данных по утвержденным работам, зарегистрированным в системе, содержащую следующую информацию: организация; подразделение; подрядчик; период, подтверждения работ договор подрядчика; утвержденные документы выполнения работ; сумма к оплате. Справка распределение после формирования должна быть готова к передаче в бухгалтерию в печатном виде. 4.4.10. Учет ГСМ Для учета ГСМ необходимо разработать Рабочий стол, в котором будет возможно выполнение функционала описанного в п. 4.4.10.1-4. 4.4.10.1. Ввод потребности Ввод потребности на ГСМ осуществлять в стандартной обработке «Ввод и согласование потребности». Но потребности по данной группе МТР необходимо консолидировать на рабочем столе по учету ГСМ. 4.4.10.2. Движение ГСМ в топливозаправщиках По факту закупки ГСМ полученный объем распределяется по топливозаправщикам на объекты работ. При выполнении работ на объектах, происходит заправка техники из топливозаправщиков в рабочую технику. Система должна позволять учитывать следующую информацию: организация; подрядчик, предоставивший топливозаправщик; топливозаправщик: 98 o вид ТС; o модель ТС; o марка ТС; o гос. номер ТС. вид ГСМ; Единица измерения; коэффициент плотности ГСМ; дата, время пополнения ГСМ; остаток ГСМ в топливозаправщике, на момент пополнения; объем пополнения ГСМ; объект работ, на который распределяется топливозаправщик. Система должна предоставлять механизм, позволяющий анализировать движение ГСМ в топливозаправщике в оперативном режиме. 4.4.10.3. Регистрация факта расхода ГСМ При выполнении работ транспортом/двигателем регистрируется факт расхода ГСМ из топливозаправщика и заправки транспортного средства. По факту расхода ГСМ ведется Ведомость по учету ГСМ, данные фиксируются в Путевом листе. Необходимо иметь отсканированные версии документов в АСУ TMS, для внесения в систему и сравнения данных. АСУ TMS должна предоставлять механизм позволяющий фиксировать данные по учету ГСМ (Ведомость по учету ГСМ), содержащую следующую информацию: организация; период ведения ведомости; подрядчик, предоставивший топливозаправщик; топливозаправщик; транспортное средство, получающее ГСМ; водитель, получивший ГСМ; работы, на которых задействован транспорт, получающий ГСМ; ответственное лицо, получающее ГСМ; 99 дата, время выполнения заправки; объем заправленного ГСМ; вид заправленного ГСМ; ФИО и должность ответственного, завизировавшего выполнение заправки. Система также должна иметь получать информацию с датчиков контроля ГСМ на двигателях. (Внешний сервис) 4.4.10.4. Сверка данных по расходу ГСМ После получения документов Ведомости по учету ГСМ и Путевого листа происходит процесс сверки данных. В АСУ TMS, с целью более удобного восприятия информации необходимо получать аналитику по данным расхода ГСМ в разрезе: ведомости по учету ГСМ; путевого листа; заведенных норм по учету ГСМ. БСМТС. При получении расхождений данных по Путевому листу и Ведомости по ГСМ происходит процесс расхождений возможностью должно выяснения причин отклонений. По перечню происходить фиксирования выяснение выясненных причин причин и отклонений, с договоренностей к конкретным отклоненным позициям (Ведомости ГСМ, Путевому листу, БСМТС (вторая очередь)). После факта выполнения сверки данных по расходу ГСМ, с выяснением причин расхождений и утверждением их, сверяемые документы, за обработанный период должны становиться не доступными к редактированию. 4.4.11. Фиксирование условий договоров 4.4.11.1. Регистрация и контроль выполнения основных параметров При работе с подрядчиками транспортных услуг. Договор заключаются договора на оказание заключается с каждым подрядчиком на 100 определенный период и содержит в себе ключевые параметры для выполнения и контроля работ (условия договора). Ниже приведены требования по регистрации и контролю условий договоров: объемы работ; место оказания услуг; тип ТС; вид ТС; гос. номер ТС; времени предоставления ТС; режим работы ТС; тарифы; штрафные санкции. Система должна позволять учитывать вышеперечисленные параметры в справочнике «Договоры контрагентов». Система должна рассчитывать нарастающий итог затрат по договору с подрядчиком, причем при достижении уровня затрат в 80% выдавать соответствующее предупреждение. Нарастающий итог затрат должен рассчитываться при проведении документа «Подтверждение отработки». Система выводит принятые и не принятые объемы работ по договору за заданный пользователем период, в отчетной форме. Не принятые объемы получаем путем вычета фактических объемов работ (в машино-часах) из запланированных. Запланированные объемы на определенный период рассчитываются как сумма машино-часов по заявленным транспортным средствам, каждого вида. 4.4.11.2. Штрафные санкции При выполнении работ возникают отклонения от условий, заключенных в договоре с подрядчиком, либо случаются события, описанные в специальном приложении к договору о штрафных санкциях. Штрафные санкции могут 101 рассчитываться как процент от ставки тарифа, так и задаваться конкретной суммой. Система должна предоставлять возможность регистрации штрафных санкций в рамках договора с подрядчиком. При регистрации должны использоваться следующие данные: пункт договора, в котором описана соответствующая штрафная санкция; нарушение – описание события, за которое выставляется штрафная санкция; производство – место возникновения штрафной санкции; метод расчета штрафной санкции: Метод расчета штрафной санкции должен задаваться при ее регистрации в АСУ MTO.TMS и задаваться как: конкретная сумма за каждый факт возникновения штрафного события; процент от стоимости тарифа транспортного средства; процент от суммы договора. Регистрация документа «Акт отклонения» в АСУ МТО.TMS позволяет применить зарегистрированные штрафные санкций, с автоматическим расчетом суммы. Штрафные санкции должны иметь статусы: занесен; утвержден. При возникновении штрафного случая, введенная в систему штрафная санкция считается занесенной, после согласования\утверждения ответственным лицом – утвержденной. Штрафные санкции должны вводиться в систему как отдельно, так и на основании документа «Акт отклонения», с информированием о необходимости введения штрафной санкции и возможностью автоматического расчета суммы, в случае указании в причине акта одного из нарушений, указанных при регистрации санкции. 4.4.11.3. Контроль наполнения характеристик ТС 102 При получении нового ТС в работу, подрядчик по условиям договора обязуется предоставить сопутствующую документацию (перечень характеристик) по предоставленному ТС. В Системе необходимо иметь возможность фиксирования следующего перечня характеристик, помимо набора характеристик, уже заложенных в систему: идентификационный номер (VIN); год изготовления; № двигателя; № шасси, рамы; мощность двигателя; рабочий объем двигателя; тип двигателя. При формировании нового элемента справочника «Транспортные средства» заложить обязательные к заполнению поля: тип ТС; вид ТС; марка ТС; гос. номер ТС. Так же к обязательным для заполнения полям отнести характеристику «Владелец ТС», владельцем может быть: контрагент; организация; физ. лицо. При отсутствии полного перечня необходимой информации по транспортному средству, например, отражены только обязательные к заполнению поля, выводить напоминание о наличии такого факта. Напоминание выводить при записи документа «Реестр подрядчика». В системе предусмотреть отчет по анализу наполнения характеристик элементов справочника «Транспортные средства». 103 Отчет должен предоставлять следующую информацию, по выбранному элементу справочника «Транспортные средства»: дата регистрации элемента в системе; автор элемента справочника; перечень заполненных характеристик; перечень не заполненных характеристик. 4.4.11.4. Контрольные сроки по «Заявке на ТС» При заключении договора с подрядчиком обговариваются сроки предоставления ключевой информации: заявка на ТС должна направляться подрядчику не позднее, чем за оговоренное количество часов до начала выполнения работ; подрядчик обязан в течение определенного количества часов с момента получения заявки подтвердить исполнение заявки – направив в ответ перечень ТС, обеспечивающих заявку. Заложить в Систему возможность настройки сроков предоставления информации, для каждого из указанных выше пунктов. Система должна отслеживать сроки последней активности документа «Заявка на ТС», путем записи времени последней отправки электронного письма из системы, с вложением печатной формы документа, либо вывода ее на печать. АСУ МТО.TMS должна сравнивать разницу времени поступления ТС на объект и дату последней активности документа «Заявка на ТС» со временем определенным в условиях договора. Сравнение должно происходить при формировании на отправку электронного письма. Значение разницы рассчитывать как разность требуемого времени поступления ТС и отправки документа «Заявка на ТС». Требуемое время поступления указано в табличной части документа. По результатам сравнения, если время фактической реакции заказчика меньше заданного в условиях договора, Система должна оповестить текущего пользователя системы. 104 В случае получения результата сравнения меньше заданного в условиях договора значения, оповещать об этом пользователя системы. При возникновении подобной ситуации выводить соответствующее сообщение пользователю, с возможностью отказа от отправки электронного письма, либо отмены вывода формы на печать. При получении перечня ТС от подрядчика в ответ на отправленную ему «Заявку на ТС» должна происходить автоматическая загрузка данного перечня в систему из утвержденного файла. При реализации автоматической загрузки Система должна понимать время реакции Заказчика и сравнивать ее с заложенными в договоре условиями. Время реакции заказчика рассчитывается как разница между временем отправки документа «Заявка на ТС» и временем загрузки перечня ТС в систему. В случае получения отклонений по вышерассмотренным условиям договоров, как со стороны подрядчика, так и со стороны сотрудников, хранить данные факты в системе, для возможности анализа в виде отчета. Отчет должен содержать следующую информацию: сроки, заложенные в договоре; фактические сроки событий; ссылка на событие, по которому отслеживаются сроки. 4.4.11.5. Тарификация При выполнении работ с каждым из подрядчиков заключаются индивидуальные расценки на стоимость работ предоставленного ими транспорта. Данные условия контрагентов». тарификации фиксируются Продолжительность действия в справочнике тарифа «Договоры соответствует сроку договора. Тарифы могут меняться в течение срока договора, например из за роста стоимости ГСМ. Изменение тарифов может задаваться пользователем вручную. Тариф задается на вид ТС, но в редких случаях задается и на конкретное транспортное средство, с указанием гос. номера. Тариф может задаваться на: машино-час; тн\км; 105 вес (тариф на сумму килограмма веса); на расстояние. В тарифах предлагается фиксировать: режим работы ТС; ставка по каждому из видов часов; стоимость мобилизации за единицу ТС; стоимость демобилизации за единицу ТС; признак включения стоимости расходов по ГСМ в тариф. Режим работы подразумевает количество часов работы ТС в смену. Виды часов перечисляются в соответствующем справочнике. Необходимо чтобы система учитывала индивидуальные условия тарифов по каждому из подрядчиков, с возможностью задания одного из двух алгоритмов расчета по видам часов: расчет тарифа за каждый час работ; расчет тарифа по непрерывному простою более определенного количества часов. Расчет тарифа за каждый час работ – если ТО было 5 часов, то и ставка на этот вид часов рассчитывается на эти 5 часов. Расчет тарифа по непрерывному простою более определенного количества часов – если ТО было более заданного количества часов, то ставка на этот вид часов рассчитывается на это количество часов, если ТО было менее данного количества часов, то считаем что ТО не было и оплачивается тариф по полной ставке. Условия тарифов должны быть частью договора с подрядчиком и быть доступными к анализу на этапах формирования документов: «Заявка на ТС»; «Лимит в технике»; «Подтверждение заявки на ТС»; «Задание на работу»; «Рейс»; 106 «Отработка». Системе необходимо тарифы по перевозке грузов, с учетом параметров: вес; расстояние; объем; количество мест; зона отправки груза; зона получения груза; вид ТС; временной интервал; загрузочный метр; сумма оценочной стоимости. «Загрузочный метр» – расчет стоимости использования ТС в зависимости от количества загрузочных метров груза; «Сумма оценочной стоимости» – расчет стоимости использования ТС, в зависимости от оценочной стоимости перевозимого груза; «Временной интервал» - расчет стоимости использования ТС, в зависимости времени работы ТС на объекте; Так же в качестве показателей расчета в АСУ МТО.TMS заложить максимальную: длину грузового места; ширину грузового места; высоту грузового места. 4.4.11.6. Контроль отсрочки платежей При фиксировании условий договоров с подрядчиком обговаривается срок отсрочки платежа по представленной подрядчиком счет фактуре. В Системе контролировать дату поступления каждой входящей счет фактуры. В условиях договора с подрядчиком фиксировать договоренность по продолжительности отсрочки. Разработать отчетную форму перечня счетов фактур, с указанием: 107 даты регистрации счет фактуры; продолжительности отсрочки; крайней даты оплаты; количества дней просрочки; сумма пени, по отсроченным платежам; оплаченные счета фактуры. Пени должна рассчитываться ежедневно, как процент от суммы просрочки. Данный процент так же указывать в условиях договора с подрядчиком. Данные об оплаченных счет фактурах хранятся в Платёжной системе заказчика, которые необходимо передать в Систему. 4.4.11.7. История работы с договором При выполнении работ учитывать исполнение условий договора, как со стороны подрядчика, так и со стороны собственных сотрудников. Система должна предоставлять возможность анализировать в виде отчетной формы, связанную с договором информацию: ключевые сроки по связанным документам; финансовые детали, объемы по договору; контроль отсрочки платежей. Система должна предоставлять информацию по ключевым срокам: дата регистрации счет фактуры входящей; количество дней отсрочки для оплаты по счет фактуре входящей; дата последней активности документа «Заявка на ТС»; дата создания документа «Лимит в технике»; дата создания документа «Реестр подрядчика». Под датой последней активности документа «Заявка на ТС» подразумевается дата последней печати или отправки электронным письмом. Система должна предоставлять информацию по финансовым деталям, объемам по договору: сумма договора; 108 объемы работ по договору (в машино-часах); процент использованной суммы; остаток суммы по договору; процент выполненных объемов работ; остаток работ по договору; оплаченные счета фактуры; сумму примененных штрафных санкций; Процент выполненных объемов работ по договору и его остаток должны выводиться, с возможностью расшифровки по документам «Реестр подрядчика», сформировавшим отработанный объем. 4.4.11.8. Ответственные лица по договору При регистрации договоров закладываются ответственные лица, как со стороны Заказчика, так и со стороны исполнителя договора. Система должна предоставлять механизм по заданию перечня ответственных лиц (ОЛ) по договору с указанием: принадлежности ОЛ к Заказчику либо Исполнителю договора; функции ОЛ; должности ОЛ; ФИО ОЛ; контактных данных ОЛ. Перечень функций задается в системе МТО.TMS. 4.5. Требования к блоку «Управление услугами» 4.5.1. Общее описание процесса учета услуг Весь процесс учета услуг можно разложить на подпроцессы: Установка финансовых лимитов o Формирование финансовых лимитов; o Согласование финансовых лимитов; Оперативное планирование потребностей на период заявочной кампании o Формирование оперативных потребностей; 109 o Согласование потребностей; Закупка услуг под потребности o Размещение лотов на электронной торговой площадке; o Получение предложений поставщиков; o Конкурсный выбор поставщика; o Заключение договора оказания услуг; o Формирование заказов на оказание услуг; o Анализ процесса поставки; Отражение факта отражения услуг o Проверка факта оказания услуг; o Проверка обязательной сертификации; o Регистрация прихода в управленческом учете; o Передача документации в бухгалтерию; o Экспорт данных из системы 1С: МТО систему Бухгалтерскую систему заказчика. Отражение факта оказания услуг в бухгалтерском и налоговом учете o Получение первичной документации по факту оказания услуг; o Проверка и проведение в бухгалтерском и налоговом учете. Часть процессов описана в п.4.2-4.5. 4.5.2. Фиксирование услуг буровым мастером Описание функциональности подсистемы «Рабочее место бурового мастера», в том числе отчет «План факт по суточному рапорту и ПТУ» будет описан в техническом задании по блоку № 3 выполняемых работ «Стационарное рабочее место». Документ «Рабочее место бурового мастера» переименовать в «Суточный рапорт». В документе «Суточный рапорт» реализовать отражение факта принятых работ по услугам. Для этого разрешить буровому мастеру отражать информацию по контрагенту и принятой услуге. Если услуга нормализована отражать количественные и суммовые показатели, если нет, только суммовые. Стоимость и 110 сумму услуг отражать пользователям только при соответствующей персональной настройке «Отражать стоимость и сумму услуг в суточном рапорте». Принятые услуги необходимо хранить в специальном регистре «Услуги для отражения в ПТУ». При проведении документа «Суточный рапорт» необходимо генерировать движения в данный регистр по отраженным к принятию услугам. Для формирования документов «Поступление товаров и услуг» (ПТУ) на основании данных о выполненных услугах, зарегистрированных буровым мастером необходимо реализовать обработку «Формирование ПТУ по услугам бур мастера». Обработка должна при помощи кнопки «Заполнить» получать информацию о выполненных услугах из регистра «Услуги для отражения в ПТУ», заполняться должны услуги, еще не принятые в документе «Поступление товаров и услуг». Информация должна содержать следующие параметры: Буровой мастер; Документ «Суточный рапорт»; Контрагент; Договор; Подразделение; Услуга; Статья затрат; Количество; Стоимость; Сумма. Данные должны быть доступны для редактирования, так как буровой мастер может не заполнить все параметры (например, стоимостные и суммовые показатели, договор). В каждой строке табличной части обработки необходимо отразить поле для флага «Выбрать» (выбор строки) для включения выбранной строки в ПТУ. Необходимо создать кнопку «Создать документы поступления услуг» для 111 формирования документов «Поступление товаров и услуг» по выбранным строкам таблицы. При формировании группировать документы «Поступление товаров и услуг» по контрагенту и договору. При включении выбранных услуг в ПТУ и согласовании ПТУ делать расходные движения по регистру «Услуги для отражения в ПТУ». Если документ «Поступление товаров и услуг» не согласован: Из регистра услуги для отражения не удалять; Не позволять включать данные записи в другой документ поступления. При пометке на удаление несогласованного документа «Поступление товаров и услуг» позволять включать услуги из помеченного документа в другие документы поступлений. Все документы, участвующие в процессе должны быть доступны в интерфейсе услуг для роли «Менеджер по учету услуг». 4.6. Общие требования к блокам системы АСУ МТО.TMS 4.6.1. Формирование плана оплат. На основании документов «Заказ поставщику», «Справка начисление» система должна формировать план оплат, используя следующие реквизиты условий договоров: Контрагент Договор Сумма Условия оплаты Период оплаты должен рассчитываться, используя данные об оплате аванс/по факту поставки. Срок оплаты наступает с даты документа поступления + срок оплаты. Учитывать просроченную оплату. План оплат должен формироваться на месяц, 3 месяца, 6 месяцев, 12 месяцев. Данные необходимы для передачи в Казначейство компании. 112 4.6.2. Бюджетный контроль. Функция процесса: осуществление превентивного бюджетного контроля по заявкам на услуги и МТР. Входные данные: потребность на оказание услуг сторонними подрядчиками или МТР. Выходные данные: согласование вхождения в бюджет потребностей. После стандартного процесса согласования введенных потребностей в АСУ МТО.TMS включаются дополнительные согласующие при достижении порогов: Информирование о расходе бюджета 80%; Утверждение потребности дополнительным лицом при расходе бюджета 100-110%; Утверждение потребности более высоким должностным лицом при превышении бюджета >110%. Данная функциональность должна быть также доступна для документа «Подтверждение отработки». 4.6.3. Управление эффективностью деятельности поставщиков. Необходимо разработать механизм УЭДП, процесс которого включает в себя следующие этапы: разработка показателей эффективности деятельности, мотивации и мониторинга для поставщика; мониторинг эффективности деятельности поставщиков; оценка эффективности деятельности поставщика. Результаты оценки эффективности деятельности поставщиков являются источником информации проведения квалификации, пересмотра квалификационного статуса поставщика. Механизм должен считать: количество отказов от поставки/оказания услуг; своевременность поставки/выполнения работ в срок в процентном отношении. 113 Данные параметры должны быть обязательными для проведения повторной квалификации. 4.6.4. Мобильный клиент. При выполнении работ\перевозок оперативно, вне зависимости от местоположения, получать актуальную информацию по состоянию транспортных средств, движению материалов или согласованию документов. АСУ МТО.TMS должна иметь мобильное приложение (клиент) «Управление процессом», с помощью которого: управлять рейсами; получать актуальные данные о состоянии транспортных средств; получать актуальные данные о расходе ДТ; устанавливать отметки об отправке/получении МТР; формировать/корректировать списание. согласовывать документы/потребности. АСУ МТО.TMS должна предоставлять всю необходимую информацию для выполнения работы на мобильном клиенте путем обмена через Web-сервисы. Интерфейс при открытии мобильного клиента должен быть в соответствии с правами доступа определенных ролью пользователя. 4.6.5. Рабочее место для буровых мастеров. Для упрощения работы сотрудников на производстве необходимо разработать в системе рабочее место для буровых мастеров. Необходимо вывести следующий функционал: Ввод и согласование потребности; Корректировка потребности; Задание на перемещение; Перемещение МТР; Перемещение ОС; Задание на списание; Формирование материальных отчётов; Требования накладные; 114 Задания на работу. В данном рабочем столе пользователи должны отмечать факт прихода/работы техники. Данное рабочее место должно быть доступно для определенной роли. Функционал также должен быть реализован в мобильном клиенте. 4.6.6. Работа системы через WEB. Система должна быть настроена для работы через WEB-сервис, используя IT требования Заказчика. 4.6.7. Обязанности исполнителя. Перед началом работ и предоставлением итогового коммерческого предложения, Исполнитель обязан: 1. Провести анализ существующего функционала систем Заказчика. 2. Разработать правила/маршруты интеграции с системами Заказчика на платформе 1С. 4.6.8. Сопровождение системы. После ввода системы в опытную эксплуатацию необходимо осуществлять сопровождение на протяжении периода тиражирования. 5. ТРЕБОВАНИЯ К СОСТАВУ И СОДЕРЖАНИЮ РАБОТ ПО ПРИЕМКЕ СИСТЕМЫ И ПОДГОТОВКЕ К ВВОДУ АСУ MTO.TMS В ДЕЙСТВИЕ 5.1. Перечень подготовительных мероприятий В ходе выполнения проекта на объектах автоматизации требуется выполнить работы по подготовке к вводу системы в действие. При подготовке к вводу в эксплуатацию АСУ АСУ MTO.TMS, должны быть выполнены следующие мероприятия: Заказчик должен: a) Назначить подразделения и должностных лиц, ответственных за подготовку ввода АСУ MTO.TMS в действие; b) Обеспечить направление пользователей на проводимое Исполнителем обучение работе с АСУ MTO.TMS. c) Исполнитель должен: 115 d) Назначить должностных лиц, ответственных за подготовку ввода АСУ MTO.TMS в действие; e) Заблаговременно (не позднее 2-х недель до обучения) согласовать с Заказчиком сроки и порядок обучения персонала; f) Обеспечить разработку и согласование с Заказчиком отчетной документации, определяющей порядок и сроки этапов ввода АСУ MTO.TMS в действие. 5.2. Общие требования Приемка Системы должна осуществляться на основании результатов испытаний. Должны быть проведены следующие виды испытаний Системы, в соответствие с ГОСТ 34.601-90: a) предварительные испытания, b) опытная эксплуатация, c) приемочные испытания. Испытания должны проводиться в соответствие с разработанным планом испытаний, который разрабатывается по окончанию этапа «Реализация» (фаза 3). Испытания Системы должны проводиться на территории Заказчика. Испытания должны проводиться в существующей системе тестирования ландшафта АСУ MTO.TMS(используются механизмы и средства, реализованные при общем внедрении системы АСУ MTO.TMS). Сроки проведения мероприятий по контролю и приемке определяются в соответствие с Календарным планом выполнения работ по созданию АСУ MTO.TMS. Участниками испытаний должны выступать: a) представители Исполнителя; b) представители Заказчика. Опорным документом при выполнении контроля качества (в части функционального объема проекта) служит данное Техническое задание. 5.3. Порядок приёмки работ 116 В соответствии с требованиями ГОСТ 34.601 испытания проводят на стадии «Ввод в действие» с целью проверки соответствия создаваемой системы требованиям настоящего технического задания. Для обеспечения проведения испытаний создается комиссия. В состав комиссии входят представители Заказчика и Исполнителя. Испытания представляют собой процесс проверки выполнения заданных функций системы, выявления и устранения недостатков в программном обеспечение, оборудование и документации. Для проверки выполнения заданных функций системы устанавливаются следующие виды испытаний: a) предварительные испытания; b) опытная эксплуатация; c) приемочные испытания. Предварительные испытания системы проводят для определения ее работоспособности и решения вопроса о возможности приемки ее в опытную эксплуатацию. Предварительные испытания выполняются после проведения Исполнителем отладки программных систем и и функционального тестирования, поставляемых представления им соответствующих документов (протоколов) об их готовности к испытаниям, а также после ознакомления персонала системы с эксплуатационной документацией. Предварительные испытания должны проводиться в соответствие с документом «Программа и методика предварительных испытаний», разрабатываемым Исполнителем по окончанию этапа «Реализация». Предварительные испытания проводятся на соответствие системы согласованным и утвержденных Заказчиком Проектным решениям, а также на работоспособность и возможность приемки Системы в опытную эксплуатацию. В ходе испытаний должны проверяться: a) качество выполнения функций Системы во всех режимах функционирования; b) полнота и достаточность объема эксплуатационной документации. Объем и методы испытаний Системы, а также характеристики системы, подлежащие проверке, должны быть изложены в «Протоколе проведения 117 Предварительных испытаний». Выявленные в ходе Предварительных испытаний ошибки и недостатки отражаются в Листе Замечаний, который является частью протокола проведения Предварительных испытаний. Опытная эксплуатация системы проводиться с целью определения фактических значений количественных и качественных характеристик системы и готовности персонала к работе в условиях функционирования системы, определения фактической эффективности системы, корректировки (при необходимости) документации. В ходе опытной эксплуатации: a) дополнительно отлаживаются программно-технические средства Системы; b) уточняется проектная и эксплуатационная документация Системы. Программа опытной эксплуатации Системы должна предусматривать: a) выявление причин неисправностей и их устранение; b) проверку готовности обслуживающего персонала к постоянной эксплуатации системы; c) изменение настроек Системы и эксплуатационной документации. В ходе опытной эксплуатации должны быть устранены ошибки в работе Системы и внесены соответствующие исправления в эксплуатационную документацию. По ходу опытной эксплуатации должен вестись Журнал опытной эксплуатации системы, в котором фиксируются все замечания к функционированию Системы и ее компонентов. Результаты опытной эксплуатации должны быть оформлены «Актом о завершении опытной эксплуатации» и допуске системы к приемочным испытаниям. Приемочные испытания (интегрированное тестирование) системы проводят для определения соответствия ее согласованным и утвержденных Заказчиком Проектным решениям, оценки качества опытной эксплуатации и решения вопроса о возможности приемки системы в промышленную эксплуатацию. Приемочным испытаниям системы должна предшествовать ее 118 опытная эксплуатация на объекте. Для планирования проведения каждого из перечисленных видов испытаний разрабатывается документ «Программа и методика испытаний», определяющий состав, объем и методы испытаний АСУ MTO.TMS. Испытания проводятся на технических средствах Заказчика. Допускается использовать технические средства, находящиеся на момент проверки в эксплуатации. При испытаниях системы необходимо проверить: a) качество выполнения комплексом программных и технических средств функций, во всех режимах функционирования системы согласно утвержденных Заказчиком Проектным решениям; b) знание персоналом эксплуатационной документации и наличие у него навыков, необходимых для выполнения установленных функций во всех режимах функционирования системы, согласно утвержденных Заказчиком Проектным решениям; c) полноту содержащихся в эксплуатационной документации указаний персоналу по выполнению функционирования системы им функций согласно во всех режимах утвержденных Заказчиком характеристики выполнения Проектным решениям; d) количественные и/или качественные автоматизированных функций системы в соответствии с утвержденными Заказчиком Проектными решениями; e) другие свойства системы, которым она должна соответствовать по утвержденным Заказчиком Проектным решениям. На приемочных испытаниях комиссией Заказчика оцениваются результаты опытной эксплуатации Системы, а также решается вопрос о возможности приемки Системы в постоянную эксплуатацию. В процессе приемочных испытаний Системы должно быть проверено: a) выполнение работ по устранению замечаний, полученных в ходе опытной эксплуатации; b) полнота и качество реализации функций, указанных в утвержденных Заказчиком Проектным решениях; 119 c) полнота и качество выполнения каждого требования, относящегося к интерфейсу Системы; d) комплектность и качество эксплуатационной документации. При проведении интеграционного тестирования и всех видов испытаний системы необходимо использовать только наборы тестовых данных, не содержащие информацию, составляющую коммерческую тайну или являющейся информацией ограниченного доступа. Выполнение задач по категорированию информации, содержащейся в используемых данных, а также оформлению соответствующего экспертного заключения об отсутствии в них информации ограниченного доступа является обязательством Заказчика. Все виды испытаний должна принимать комиссия, состав которой определяется проведении приказом (распоряжением, испытаний. представители Заказчика, В состав постановлением, приемочной представители протоколом) комиссии Исполнителя, а о включаются также иные заинтересованные лица, по решению Руководящего органа Проекта. 5.3.1. Приёмка системы и передача в промышленную эксплуатацию По окончании испытаний их результаты фиксируются в протоколах. Работу завершают оформлением Акта сдачи-приемки Системы в постоянную эксплуатацию. Сроки ввода системы в опытную и постоянную эксплуатацию определяются Заказчиком и согласуются с Исполнителем. После ввода системы в постоянную эксплуатацию Исполнитель должен обеспечить период гарантийного сопровождения. В период сопровождения АСУ MTO.TMS в ходе опытной эксплуатации Исполнитель обязан следить за ходом эксплуатации и обеспечить исправление всех возникающих неисправностей и недоработок в работе программного обеспечения и ошибок в технической документации, обеспечить полноту и целостность базы данных. В период гарантийного сопровождения Исполнитель обязан обеспечить исправление всех возникших сбоев программного обеспечения. Период 120 гарантийного сопровождения АСУ MTO.TMS устанавливается на срок 12-18 месяцев с момента подписания акта приемки АСУ MTO.TMS в постоянную эксплуатацию. 121 6. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ Вся документация Проекта должна быть разработана на основании и в рамках единых шаблонов, подготовленных и утвержденных в Уставе Проекта. Перечень подлежащих разработке документов по стадиям проекта определен в таблице: Фаза Фаза 0 Этап Формирование НСИ Подготовка проекта Итоговые документы Детальный план-график выполнения работ. Перечень НСИ Доработанные и согласованные шаблоны сбора данных (включая классификатор оборудования). Методика сбора и подготовки базы данных по оборудованию. планов и Заполненные шаблоны загрузки данных по планам ППР и стратегиям ремонтов. ремонтов Формирование стратегий оборудования Фаза 1 Подготовка проекта Фаза 2 Проектирование и реализация Фаза 3 Заключительная подготовка Устав проекта. Детальный план-график выполнения работ по проекту (Фаза 1). Приказ по предприятию о назначении руководителя работ и лиц, ответственных за реализацию Проекта. Альбом шаблонов документов по проекту. Разработка программного кода: Описание настроек. Протокол функционального тестирования. Сценарии интеграционного тестирования. Протокол интеграционного тестирования. Реестр и график устранения замечаний. Протоколы загрузки в продуктивную систему данных по оборудованию Протоколы загрузки в продуктивную систему данных по технологическим картам, планам ППР и стратегиям ремонтов График обучения конечных пользователей. Ведомости обучения. Эксплуатационная документация (руководства пользователей, руководства администраторов). Программа опытно-промышленной эксплуатации. Протокол о готовности перехода в опытно-промышленную эксплуатацию. Описание системы 122 Фаза Фаза 4 Фаза 5 Этап Итоговые документы ОПЭ Реестр и график устранения замечаний с отметками об устранении. Протокол о готовности перехода в промышленную эксплуатацию. Переход в промышленную Акт передачи системы в ПЭ эксплуатацию Приказ о вводе системы в ПЭ 123 7. ТЕРМИНЫ, ОПРЕДЕЛЕНИЯ, СОКРАЩЕНИЯ В разделе приведены значения терминов и определений, которые используются в настоящем документе, если по тексту прямо не указано иное, а также сокращения и их расшифровка. Термины и сокращения АСУ MTO.TMS ББ БД Бизнеспроцесс БМ Заказчик ЗК ИС Исполните ль КИС НСИ ПГ СО ТМЦ ТОРО ТТ Определение Автоматизированная система управления бизнес-процессами материально-технического и транспортного обеспечения Буровая бригада – основная производственная единица Базы данных Последовательность операций, создающих определенный продукт (результат), имеющий ценность для потребителя Буровой мастер – руководитель буровой бригады ООО «Газпром бурение» Закупочная комиссия Информационная система Выбранный в результате проведения закупочных процедур исполнитель работ по данному ТЗ Корпоративная информационная система Нормативно-справочная информация Проектная группа Сервисная организация Товарно-материальные ценности Техническое обслуживание и ремонт оборудования Утвержденные технические требования 124 ПРИЛОЖЕНИЕ А ОРИЕНТИРОВОЧНЫЙ КАЛЕНДАРНЫЙ ПЛАН РАЗРАБОТКИ И ТИРАЖИРОВАНИЯ 125 8. УПРАВЛЕНИЕ ДОКУМЕНТОМ 8.1. Лист согласований Подпись Дата ФИО Разработал Согласовано от ООО «Газпром бурение»: Заместитель Генерального директора по финансам и экономике Мельников Д.В. Главный бухгалтер Дубовик В.В. Заместитель Генерального директора по обеспечению и комплектации Начальник отдела информационных технологий и связи Начальник отдела внедрения информационных систем Начальник отдела стандартизации и менеджмента качества Шумелишский М.В. Рыжков А.Н. Андрианов К.И. Рогачев Ю.В. 126 8.2. Лист регистрации изменений № Изм № раздела, подраздела, пункта Номер ТЗ, к которому относится листа изменения Дата введения изменения Дата внесения Подпись лица изменения внесшего изменения
