Главная страница

ОСТАЛОСЬ ФОРМАТНУТЬ. Служба доставки (клиенты, график доставки, транспорт, маршрут)


Скачать 1.08 Mb.
НазваниеСлужба доставки (клиенты, график доставки, транспорт, маршрут)
Дата02.02.2022
Размер1.08 Mb.
Формат файлаdocx
Имя файлаОСТАЛОСЬ ФОРМАТНУТЬ.docx
ТипРеферат
#349494
страница2 из 4
1   2   3   4

Характеристика документооборота, возникающего при решении задачи


Основными документами в рассматриваемой задаче являются Заказ, Путевой лист и Получение заказа. Схема документооборота приведена в таб. 1.1

Таблица1.1 - Схема документооборота




Менеджер

Водитель

Архив

Заказ

Заказ

Оплата

Оплата

Список заказов

Список заказов




Путевой лист










Получение заказа










Существующий способ учета связан с большой трудоемкостью, разрозненностью сведений, что с большой вероятностью ведет к их утере или неправильной интерпретации. На сегодняшний день невозможно получить сведения о загрузке транспортных средств, о своевременности доставки заказов, провести анализ основных причин проблем с доставкой и выявить ответственных.

Кроме того, в отчетный период необходимо составление аналитических отчетов, включающих в себя анализ работы за определенный период, что очень затруднительно.

Временные характеристики описанных процессов приведены в таблице 1.2.

Таблица 1.2 - Характеристики описанных процессов

Действие

Среднее количество

за рабочий день

Время, необходимое для выполнении одного действия, минут

Общее время, минут

Заказ

10

15

150

Путевой лист

5

25

120

Получение заказа

0,5

60

30

ИТОГО, минут:

300



Таким образом, ежедневно, в среднем, 300 минут или 5 часов минут, сотрудник занят занесением необходимых сведений в книги учета, а также, при необходимости анализом и поиском нужных сведений. Учитывая, что продолжительность рабочего дня составляет 8 часов, делаем вывод, что на выполнение остальных обязанностей остается менее 35 % рабочего времени, что крайне неэффективно.

Для данного способа также характерны следующие недостатки:

• невысокая скорость и точность выполнения расчетов;

• неэффективное использование рабочего времени;

• слабый контроль работы сотрудника;

• бюрократия – увеличивающийся «поток» бумажной работы.

В результате проводимой автоматизации предполагается постоянно иметь точнейшие сведения о количестве поступившего и отпущенного товара, сократить время на подготовку аналитических отчетов и передачу документов за счет их электронной формы.

Очевидно, что для автоматизации необходимо использовать такие средства, как персональные компьютеры, принтеры, а также специальное программное обеспечение и, возможно, локальную вычислительную сеть.

Проведем расчет ожидаемого эффекта от внедрения средств автоматизации. В таблице 1.3 произведен расчет эффекта внедрения.

Таблица 1.3 - Расчет эффекта внедрения

Действие

Среднее количество

за рабочий день

Время, необходимое для выполнения одного действия, минут

Общее время, минут

Заказ

10

1

10

Путевой лист

5

2

10

Получение заказа

0,5

5

2,5

ИТОГО, минут:

12.5

Таким образом, ожидаемая экономия рабочего времени составляет около 5 часов ежедневно, что позволяет увеличить эффективность работы сотрудников.


  1. Разработка и реализация проектных решений

2.1 Логическое моделирование предметной области

Перед непосредственной разработкой базы данных построим информационно-техническую модель системы после осуществления входа в нее, в которой фиксируются последовательности и взаимосвязи решения всего комплекса задач по проекту.



Список транспорта








Список путевых листов





Список заявок на перевозку







Список заявок на ремонт








Список маршрутов перевозок





Рисунок 2.1 – Информационно-технологическая модель
Подробное описание представлено далее, в проектировании базы данных.

В функционал экономиста входят вопросы учета поступающих заявок на перевозки, формирование аналитической отчётности в рамках процесса оказания услуг пассажирских перевозок, а также учета затрат на ГСМ. Функционал диспетчера предполагает учет параметров автопарка, пробега автотранспорта, а также данные о фактическом использовании ГСМ.

Функционал Администратора включает ведение внутренних классификаторов, а также установку прав доступа к системе.


    1. Разработка базы данных



На основании определенных сущностей информационной системы по учету перевозок построим диаграмму «Сущность - Связь»

Каждый оператор вводит множество заявок. Связь 1:N. Каждой модели ТС соответствует множество автомобилей в автопарке. Связь 1:N. Каждому виду топлива соответствует множество моделей ТС. Связь 1:N. Каждому пункту назначения соответствует множество путевых листов. Связь 1:N. Каждому автомобилю соответствует множество путевых листов. Связь 1:N. Каждый водитель вводит множество путевых листов. Связь 1:N. Каждый сотрудник использует транспортные средства множество раз. Связь 1:N. Каждый сотрудник делает множество заявок на перевозки.

В результате работы системы учета перевозок, формируются несколько таблиц, отражающих процесс работы транспортного отдела. Данные для построения этих таблиц берутся из справочников, а также журнала работы с заявками.

Таблица 1.4 Таблица «Операторы»


Наименование

Идентификатор

Тип поля

Длина

Прочее

Идентификатор

оператора

code_oper

число

10

Первичный

ключ

ФИО

Fio

cтрока

50




Роль в системе

Rol

число

1




Пароль

passw

cтрока

50





Таблица «oper» служит для хранения информации об операторах системы и разграничения доступа. Средний объем записей 20.
Таблица 1.5 Таблица «Перевозки»


Наименование поля

Идентификатор

Тип поля

Длина

Прочее

Идентификатор

путевого листа

Code_vt

число

10

Первичный

ключ

Идентификатор

водителя

Code_v

число

10

Вторичный

ключ

Идентификатор

автомобиля

code_sotr

число

10

Вторичный

ключ

Дата

Day

Дата







Фактический пробег

Prob

число

10




Затраты

Stm

Денежный







Расход ГСМ

Rash

число

10




Идентификатор

места назначения

Code_pn

число

10

Вторичный

ключ

Примечание

prim

строка

200




Идентификатор

клиента

Code_с

число

10

Вторичный

ключ

Идентификатор

заявки

Code_z

число

10

Первичный

ключ


Таблица «plist» служит для хранения информации о путевых листах.

Средний объем записей 100000. Далее приведем описание кодирования ключевых сущностей проектируемой ИС и их свойств.


Таблица 1.6 Описание систем классификации и кодирования



п/

п

Наименование кодируемого множества

объектов

Значность кода

Система кодирован

ия

Вид классификато

ра

1

2

3

4

5

1

Код вида услуги перевозки

ХХ

порядковая

локальный

2

Код клиента

ХХХ ХХХХХ

серийно порядковая

локальный

3

Код ТС

ХХХ

порядковая

локальный

4

Код перевозки

ХХХХ ХХХХХ

серийно-

порядковая

локальный

5

Код ГСМ

ХХХХХ ХХХХ

порядковая

локальный




  1. Код вида услуги перевозки. Длина кода ХХ, где ХХ – порядковый номер вида услуги перевозки в картотеке транспортной компании.

  2. Код клиента. Длина кода ХХХ ХХХХХ, где ХХХ – порядковый номер категории, ХХХХХ – порядковый номер клиента.

  3. Код ТС. Длина кода ХХХ, где ХХХ – порядковый номер транспортного средства, зарегистрированного в системе.

  4. Код перевозки. Длина кода ХХ ХХХХХ, где ХХ – порядковый номер ТС, ХХХХХ – порядковый номер услуги перевозки.

  5. Код ГСМ. Длина кода Х, где Х – порядковый номер вида ГСМ.




    1. Физическое моделирование АИС
      1. Архитектура АИС


В качестве архитектуры решения будет применяться многослойная клиент-серверная архитектура, поскольку уже используемые на АТП решения на базе 1С: Предприятия организованы на базе такой архитектуры. Для клиент- серверной архитектуры, характерно отделение процессов представления, обработки и управления данными. Модель клиент-серверной архитектуры помогает создавать гибкое программное обеспечение. Изменения в данной модели осуществляются не во всем приложении сразу, а лишь в конкретных слоях, что позволяет сократить количество потенциальных ошибок и времени на модернизацию. Для клиент-серверных систем характерно наличие самостоятельно взаимодействующих процессов, выполнение которых, в общем случае, может производиться на разных вычислительных системах путем обмена данными по сети.

Слой клиента это компонент комплекса, реализующий интерфейс конечного пользователя. Данный слой не имеет возможности взаимодействовать с базой данных напрямую, на него обычно выносится простая бизнес–логика, такая как: интерфейс организации, контроль вводимых значений, сортировка, группировка и другие простые операции. В случае решения может быть как полновесной программой клиентом, так и «тонким» и даже веб-клиентом.



Клиентское

приложение

(интерфейс)










Серверное

приложение









Слой клиента





Слой логики

Слой данных

Рисунок 2.6 Модель многослойной архитектуры

Слой логики – реализует большую часть бизнес-логики. Вне этого уровня реализуются элементы логики, экспортируемые на клиента, а также хранимые процедуры в БД. Данный компонент реализуется связующим программным обеспечением, на предприятии это платформа 1С: Предприятие.

Слой данных – как правило представляет собой СУБД, обеспечивающую хранение данных. Взаимодействовать с третьим уровнем может только второй уровень. Слой данных на предприятии уже реализован на базе MS SQL Server 2008.
В созданной конфигурации имеются следующие справочники (таб 1.7)

Таблица 1.7 Сводная таблица справочников

Название справочни-ка;

Ответственный за его ведение;

Средний объём справочника в записях;

Средняя частота актуализации;

Средний объем актуализации (в записях или в процентах);

Договоры

Менеджер

5

1 раз в месяц

20

Заказчики

Менеджер

30

1 раз в месяц

30

Страна_Производитель

Менеджер

10

1 раз в месяц

20

Сотрудники

Менеджер

10

1 раз в месяц

30

В таб. 1.8 описаны характеристики справочника Договоры

Таблица 1.8 Договоры

Номенклатура поля

Идентификатор поля

Тип поля

Длина поля

Код

Код

Счетчик




Название

Название

Строка

10

В таб. 1.9 описаны характеристики справочника Заказчики

Таблица 1.9 Заказчики

Номенклатура поля

Идентификатор поля

Тип поля

Длина поля

Код

Код

Счетчик




ФИО

Номенклатура

Строка

20

Телефон

Телефон

Строка

10

Адрес

Адрес

Строка

10

В таб. 2 описаны характеристики справочника Автомобили

Таблица 2 - Автомобили

Номенклатура поля

Идентификатор поля

Тип поля

Длина поля

Код

Код

Счетчик




Название

Название

Строка

20

Гос_Номер

Гос. номер

Строка

10

Цвет

Цвет

Строка

20

В таб. 3 описаны характеристики справочника Водители

Таблица 3 - Водители

Номенклатура поля

Идентификатор поля

Тип поля

Длина поля

Код

Код

Счетчик




ФИО

ФИО

Строка

20

Адрес

Адрес

Строка

20

Телефон

Телефон

Строка

10

Стаж

Стаж

Число

10

На рисунках 2.1-2.4 отражены формы справочников данной конфигурации





Рисунок 2.1 Справочник Договоры



Рисунок 2.2 Справочник Автомобили





Рисунок 2.3 Справочник Водители





Рисунок 2.4 Справочник Заказчики

Экранные формы размещения данных описаны в таблице 4

Таблица 4 - Описание входных документов

пп

Наименова-ние

Реквизиты

Таблицы, на основе которых формируется

Частота формирования

1

Заказ

  • Номер

  • Дата поставки

  • Заказчик

  • Договор

  • Сумма

  • Договоры

  • Заказчики

  • Ежедневно

2

Поставка

  • Номер

  • Водитель

  • Дата доставки

  • Автомобиль

  • Водители

  • Автомобили

3

Получение_Заказа

  • Номер

  • Дата

  • Договор

  • Оплата

  • Заказчик

  • Оплата доставки

  • Договоры

  • Заказчики

  • По мере необходимости

Экранные формы (макеты) документов и экранные формы для их ввода в систему изображены на рисунках 2.5-2.7





Рисунок 2.5 Документ Заказ





Рисунок 2.6 Документ Путевой_Лист



Экранные формы отчетов описаны в таблице 5

Таблица 5 - Описание выходных документов

пп

Номенклатура

Реквизиты

Таблицы, на основе которых формируется

Частота формирования

1

Загрузка автомобилей

  • Номер

  • Дата доставки

  • Автомобиль

  • Автомобили

  • Ежедневно

2

Занятость водителей

  • Номер

  • Дата доставки

  • Автомобиль

  • Водители

  • Ежедневно

3

Заказы

  • Договор

  • Дата поставки

  • Сумма

  • Заказчики

  • Договоры

  • Ежедневно


  1. 1   2   3   4


написать администратору сайта