Файл: Автоматизация учета выполнения заказов ООО "Ripair".pdf
Добавлен: 01.04.2023
Просмотров: 311
Скачиваний: 4
СОДЕРЖАНИЕ
1.Технико-экономическая характеристика предметной области и предприятия
1.1. Характеристика предприятия и его деятельности
1.2. Организационная структура управления предприятием
1.3. Выбор комплекса задач автоматизации и характеристика существующих бизнес процессов
2.Информационное обеспечение задачи
2.1. Информационная модель и её описание
2.3. Характеристика нормативно-справочной, входной и оперативной информации
2.4. Характеристика результатной информации
3.Программное обеспечение задачи
3.1. Общие положения (дерево функций и сценарий диалога)
3.2. Характеристика базы данных
3.3. Структурная схема пакета (дерево вызова программных модулей)
Рисунок 6 – Декомпозиция БП «Рассмотрение заявки и техники»
Рисунок 7 – Декомпозиция БП «Выполнение ремонта и модернизации ПК»
В результате рассмотрения бизнес-процесса необходимо выполнить автоматизацию и обеспечение безопасности приема заявок на ремонт и модернизацию ПК при использовании информационных технологий.
В результате можно сделать вывод, что организация выполнения заказов на ремонт и модернизацию ПК, в основном, зависит от бизнес-процессов, протекающих в ООО «Ripair», а не от непосредственно руководства компании.
2.Информационное обеспечение задачи
2.1. Информационная модель и её описание
Источниками первичной информации являются договора о предоставлении товаров, товарно-транспортные накладные, метод ввода – вручную.
Адресатами выдачи информации являются конечные пользователи и администрация ООО «Ripair». Данная информация предназначается для анализа хозяйственной деятельности компании.
В результате выполнения преобразования информации будет создан реестр выполнения заказов.
Рисунок 8 – Информационная модель автоматизированной ИС
2.2. Используемые классификаторы и системы кодирования
В составе информационного обеспечения рассматриваемого комплекса задач важное место отводится классификаторам экономической информации:
Обеспечить сжатие призрачной части показателей, а, следовательно, и сократить объем хранимой информации в ЭВМ и время на поиск информации, необходимой для решения задач, облегчить обработку информации позволяют классификация и кодирование информации.
Кодированием называется процесс присвоения объектам кодовых обозначений. Основная цель кодирования состоит в однозначном обозначении объектов, а также в обеспечении необходимой достоверности кодируемой информации.
При проектировании кодов предъявляется ряд требований:
- охват всех объектов, подлежащих кодированию, и их однозначное обозначение;
- возможность расширения объектов кодирования без изменения правил их обозначения;
- максимальная информативность кода при минимальной его значности.
Различают иерархическую и многоаспектную системы классификации.
В соответствии с приведенными требованиями к кодам в разрабатываемом проекте используется серийная система кодирования, позволяющая кодировать установившееся несложные множества объектов, учитывая возможность расширения кодируемого множества и разбиение по одному признаку классификации.
В составе информационного обеспечения рассматриваемого комплекса задач выделены следующие классификаторы:
- классификатор сотрудников;
- классификатор услуг;
- классификатор клиентов.
Структурная формула классификаторов:
0000000X,
где Х – порядковый номер записи.
2.3. Характеристика нормативно-справочной, входной и оперативной информации
Информационной моделью системы автоматизации учета выполнения заказов является совокупность входных, результативных, оперативных потоков и функций для их обработки.
Также с ее использованием объясняется тот факт, что для массивов входной документации будет выполнен ряд необходимых функций, что и являются основоположными для отдельной АИС.
Для обеспечения процесса хранения постоянной информации о поставках применяются справочники (входная информация):
– Отделы;
– Услуги;
– Клиенты.
Рассмотрим более подробно описание водной информации, которая представлена с помощью справочников.
Таблица 2
Справочник «Отделы»
Имя |
Тип |
КодОтдела |
Число (целое) |
НазваниеОтдела |
Строка (текст) |
НачальникОтдела |
Строка (текст) |
Кабинет |
Число (целое) |
Справочник «Услуги» предназначен для хранения данных об услугах ООО «Ripair» (таблица 3).
Таблица 3
Справочник «Услуги»
Имя |
Тип |
Код услуги |
Число (длина 3) |
Наименование услуги |
Строка (текст) |
Стоимость услуги |
Числовой |
Время выполнения |
Числовой |
Справочник «Клиенты» использован для хранения данных о поставщиках ООО «Ripair» (таблица 4).
Таблица 4
Справочник «Клиенты»
Имя |
Тип |
Код клиента |
Число (длина 3) |
Название клиента |
Строка (текст) |
Адрес клиента |
Строка (текст) |
Пол клиента |
Перечисление |
Телефон клиента |
Строка (текст) |
Входные данные в базу данных могут вводиться в систему двумя методами:
– вручную;
– при использовании формы.
Пример тестовой информации созданных справочников показана рисунке 9:
Рисунок 9. Экранная форма справочника Клиенты
В таблице 5 рассмотрена сводная информация по справочниках:
Таблица 5
Сводная таблица по справочниках
Название справочника |
Услуги |
Отделы |
Клиенты |
Ответственный за его ведение |
Менеджер по работе с клиентами |
Менеджер по работе с клиентами |
Менеджер по работе с клиентами |
Средний объем справочника в записях |
25 |
15 |
35-40 |
Средняя частота актуализации |
1 раз в квартал |
1 раз в год |
1 раз в месяц |
Средний объем актуализации, записей |
1-2 |
1 |
2-3 |
2.4. Характеристика результатной информации
Объект платформы 1С:Предприятие под названием документ применяется для хранения оперативных данных.
Стоит отметить, что в рассматриваемой задаче для автоматизации выполнения заказов ООО «Ripair» такой информацией являются данные с заявки.
Таблица 6.
Документ Учет заказов
Имя |
Тип |
Номер |
Число (целое) |
Дата оформления заказа |
Строка (текст) |
Клиент |
Подстановка СправочникСсылка.Клиенты |
Отдел |
Подстановка СправочникСсылка.Отдел |
Услуга |
Подстановка СправочникСсылка.Услуги |
Оплачено |
Булевое |
Подпись |
Строка (текст) |
Таблица 7.
Документ Сотрудники
Имя |
Тип |
КодСотрудники |
Числовой |
ФИО |
Строка (текст) |
Адрес |
Строка (текст) |
Отдел |
Подстановка СправочникСсылка.Отдел |
Телефон |
Строка (текст) |
Пол |
ПеречислениеСсылка.Пол |
Стоит отметить, что в документах применяются ссылки на все справочники, которые описаны выше.
Ниже, на рисунках 10 и 11, показаны экранные формы документов:
Рисунок 10. Экранная форма документа Учет заказов
Рисунок 11. Экранная форма документа Сотрудники
Документы заполняются по необходимости, а именно:
– документ Учет заказов заполняется при формировании нового заказа;
– документ Сотрудники заполняется при оформлении на работу нового сотрудника.
3.Программное обеспечение задачи
3.1. Общие положения (дерево функций и сценарий диалога)
Программное обеспечение для автоматизации учета выполнения заказов предусматривает работу одного пользователя. Дерево функций, что реализованы в системе, представлены ниже на рисунке 12.
Рисунок 12. Дерево функций
Заметим, что имеющиеся функции разделены между несколькими подсистемами.
К примеру, информация, которая может влиять на ведение управленческого и бухгалтерского учета будет присутствовать в подсистеме под названием Бухгалтерия.
Стоит заметить, что некоторые из объектов могут брать участие в нескольких подсистемах.
На базе имеющихся данных опишем последовательность работы с конфигурацией.
На рисунке 13 рассматривается сценарий диалога.
Пункт Действия описывает возможные действия с объектами конфигурации.
Пункт Справочники используется для ввода первичных данных в базу данных.
Пункт Документы применяется для ввода оперативной информации о деятельности сервисного отдела.
Пункт Отчеты используется для вывода результатной информации по выполнению заказов.
Пункт Выход используется для закрытия конфигурации.
Рисунок 13 – Сценарий диалога
3.2. Характеристика базы данных
После анализа исходных данных надо выделить совокупность используемых объектов базы данных:
– Сотрудники;
– Услуги;
– Отделы;
– Клиенты;
– Учет заказов.
Реквизитный состав данных сущностей представлен в таблицах 2 – 6.
Рассмотрим далее определенные связи между объектами, а также разработаем ER-диаграмму.
Между объектами Отделы и Сотрудники присутствует бинарная связь «один-ко-многим», так как один отдел может иметь в составе несколько сотрудников организации.
Между объектами Учет заказов и Сотрудники есть связь «один-ко-многим», так как 1 сотрудник может присутствовать несколько раз в документе Учет заказов.
Между объектами под названием Клиент и Учет заказов будет присутствовать связь «один-ко-многим», поскольку один клиент несколько раз может обращаться в сервисный центр несколько раз.
Между объектами Услуги и Учет заказов используется связь «один-ко-многим», так как одна предлагаемая услуга может входить несколько раз в документ Учет заказов.
Рассмотрим ER-диаграмму, показанную на рисунке 14:
Рисунок 14 – ER-модель
3.3. Структурная схема пакета (дерево вызова программных модулей)
Разработанная конфигурация в себя включает непосредственно модуль, разработанный в конфигурации, а также платформу (серверную ее часть).
Платформа в данном случае является базой для создаваемого модуля и осуществления на ее основании всех основных функций для программного продукта.
Численность уровней вложенности для всех вызовов процедур в разработанной конфигурации возросло и анализ работы отдельных программных инструментов превращается порой в сложнейший механизм.
Чтобы как-то облегчить указанный процесс работы, разработано дерево вызовов для спроектированных объектов (рисунок 15).
Рисунок 15 – Дерево вызовов
3.4. Описание программных модулей
Рассмотрим далее программные модули, что представляются в разрабатываемой конфигурации: