Ниже описаны основные процессы в упрощенном виде, происходящие в системе при осуществлении деятельности автовокзала.
После установки и настройки системы и оборудования в информационной базе автовокзала создаются остановки, которые привязаны к текущему серверу данных. На основе ряда остановок с указанным порядком следования создаются маршруты. На основе маршрутов создаются регулярные рейсы с заданным временем следования по маршруту (время прибытия и отправления, периодичность), с определенным перевозчиком и его транспортным средством. На основе регулярных рейсов, при помощи фонового задания, создаются конкретные рейсы на определенный день, к которым будут привязываться проданные билеты. Для рейсов устанавливаются тарифы.
При продаже билета в рабочем месте кассира производится поиск действующих рейсов с указанным пунктом назначения и выбранной датой. После выбора конкретного рейса создается заказ в который добавляются билеты. При добавлении билетов и услуг в заказ их стоимость рассчитывается с учетом установленных тарифов, применяемых сборов, льгот и услуг. Для выбранного рейса обновляется информация о занятости мест. После оплаты текущего заказа создается запись о произведенной оплате, создаются билеты и записи о физических лицах пассажиров, обновляется информация о билетах и занятости мест текущего рейса.
Управление рейсами осуществляется в рабочем месте диспетчера. При отправлении рейса, формируется посадочная ведомость и передается перронным контролерам, после этого продажи на рейс прекращаются. При получении ведомости от перронного контролера диспетчер вносит данные о неявившихся пассажирах в посадочную ведомость. После того как ведомость сформирована регистрируется задолженность автовокзала перед перевозчиком.
Эксплуатация – раздел содержит в себе все необходимые инструменты для создания расписания, контрагентов, льгот и услуг, установки стоимости проезда, определения сборов автовокзала, правил продаж и отчеты по организации перевозок.
РМД (рабочее место диспетчера) – раздел содержит инструменты для осуществления диспетчерской деятельности: список рейсов, по которому диспетчер производит те или иные действия (печать посадочной ведомости, отправка, регистрация, отмена рейсов, вычеркивание пассажиров и т.д)
РМК (рабочее место кассира) – раздел содержит инструменты для осуществления продажи билетов и услуг на автовокзале: заказы билетов и услуг, оплаты и возвраты оплаты, реализации и возвраты услуг и т.д.
Деньги – раздел содержит инструменты для контроля и управления денежными средствами на автовокзале: приходные и расходные кассовые ордера.
Отчеты – раздел содержит список доступных для данного пользователя отчетов.
Справка - раздел, аналогичный РМД, только с урезанным списком операций над рейсами (в основном просмотр справочной информации)
Основной стек - python 3, django 3, postgre SQL, nginx.
Работает на асинхронном сервере Daphne/asgi.
Все процессы на supervisor.
Для регламентных задач и асинхронного взаимодействия используется redis, регламентные задачи на celery + часть заданий на кроне (создание бекапов).
Конфиги для разных сред задаются в директории settings_conf главного приложения, выбор того или иного конфига регулируются параметрами среды.
На фронте - bootstrap + jquery, за основу взят шаблон dore (кроме приложение terminal, там используется полностью кастомный шаблон)
Статика css и js по приложениям не разбивается, находится все в одном месте. Для автоматического сброса кеша на клиентах файлы версионируются (перед очередным релизом увеличивается номер версии конкретного файла).
Для разработки новых фич создаем ветку от мастера, после завершение создаем pull request на ветку полигон, после завершения тестирования ветка вливается в master.
Полигон деплоится автоматически по CI/CD bitbacket`а, на прод доработки заливаются по SSH.
Основное приложение для разграничения доступа пользователей по компаниям.
Все необходимые модели наследуются от базовой CompanyRLS, в которой задана ссылка на компанию.
Все пользователи имеют доступ к данным только в рамках своей компании.
Для быстрого получения данных в запросах только своей компании создан UserRLSQuerySet.
Таблица Profile - расширение базовой модели User, все операции с пользователями происходят через эту модель.
В этом же приложении задаются модели Section и Role, доступ к пользователей к разделам осуществляется по присвоенным ролям.
Для продажи билетов внешних компаний по API создан модуль api_handlers, в базовом классе BaseAPI прописаны все методы, необходимые для полноценной продажи билетов по API.
В модулях b1C_avibus, b1С_81_lib, kvc_lib прописаны методы для первоначальной загрузки данных из внешних систем.
Содержит все модели необходимые для организации перевозок.
Подмодуль organization - таблицы, связанные с данными по перевозчикам (Перевозчики, автобусы, схемы мест, водители и т.д)
Подмодуль settings - Виды льгот, тарифов, установка тарифов, типы документов, виды возвратов и т.д, т.е все настройки, необходимые для создания рейсов и продажи билетов.
Подмодуль routing - Страны, регионы, остановки, типы маршрутов + другие вспомогательные справочники.
Таблица "регулярные рейсы" (RegularTrip) - шаблон расписания, по которому будет создаваться уже конкретные рейсы (Trip)
Почти все таблицы вынесены в раздел "Эксплуатация".
Таблицы выводятся при помощи универсальных представлений (построено на django-tables + django-filters)
StandardList - список объектов
StandardUpdate - вьюха обновления данных
StandardCreate - вьюха создания данных
StandardAutocomplete - автокомплит для инпутов
StandardCreateFast - вьюха упрощенного создания и редактирования объектов.
Для быстрого конфигурирования вывода моделей задаются следующие параметры в моделях:
table_field - список полей, которые будут выведены в таблицах;
filter_fields - список полей, которые будут доступны в фильтрах;
fast_create_fields - список полей, которые будут доступны форме быстрого редактирования объекта;
Для полноценного функционирования модели в пользовательском интерфейсе необходимо описать 4 класса вьюхи (список, создание, редактирование, автокомплит), унаследовав их от базовых представлений и указав в конструкторе необходимые параметры. Также необходимо прописать роутинг в urls.py.
Для форм также существуют универсальны классы StandardObjectForm и StandardFastCreateForm, все отдельные формы таблиц необходимо наследовать от них.
В рабочем месте диспетчера все операции с рейсами обрабатывает представление RMD, где вызывается конкретных action запроса.
Данные по рейсам обновляются автоматически по веб-сокету.
Приложение для продажи билетов через кассу.
В подмодуле моделей sale находятся все модели, необходимые для оформления билетов (пассажиры, виды льгот, справочник доп.услуг и т.д).
Ключивые сущности - заказ (Order) и билет (Ticket). В рамках одного заказа может оформляться несколько билетов.
Заказ может с типом "продажа" и с типом "возврат", соответственно в рамках одного заказа можно также вернуть несколько билетов.
В подмодуле equipment находятся вспомогательные модели (оборудование, кассовые смены и т.д).
Продажа билетов происходит в рабочем месте кассира (РМК), оформление происходит в 4 этапа, каждый этап обрабатывает свое представление (RMK_step1, RMK_step2 и т.д):
1 шаг - выбор пункта прибытия, даты, количества пассажиров;
2 шаг - выбор мест на схеме. Этот шаг может быть пропущен, если выбор на схеме недоступен (например, для транзитных рейсов или стоячих мест), переадресация на следующий шаг;
3 шаг - ввод данных пассажиров (ФИО, льготы и т.д), на этам же этапе можно выбрать опцию страховки, а также добавить или удалить пассажиров.
4 шаг - этап оплаты. На этом этапе происходит взаимодействие с кассовым оборудованием и выполняется непосредственная регистрация чеков в системе.
Также на этом этапе есть дополнительная возможность зафиксировать билеты в случае проблем при пробитии на обрудовании.
Через РМК также осуществляется продажа доп.услуг (через свое представление).
Возврат билетов и услуг одношаговое, для возврата билетов также доступен групповой возврат.
Система контроля доступа автовокзала проверяет наличие билетов по штрихкоду, также проверяет возможность прохода пассажира по дополнительным условиям (пассажир не вернул билет, рейс не ушел и т.д).
На турникете запущен скрипт, который коннектится по веб-сокету (AccessControl в consumers.py), получает на вход ШК и выдает возможность прохода.
Проходы через турникет логируются в таблице AccessControlLog.
Приложения для оперативного учета денежных средств.
Помимио справочных данных (кассы, кассы ККМ, виды движения денежных средств) содержит две модели RKO (расходный кассовый ордер) и PKO (приходных кассовый ордер), фиксирующие соответственно расход и поступление д/с в кассу.
Таблицы Currency и CurrencyKKM вспомогательные, для упрощения расчетов остатков и движений денег в кассах.
Приложение для продажи билетов сторонними агентами.
Типовой функционал библиотеки Django REST framework.
Основные методы - запрос справочной информации (список документов, стран, остановок, расписания), доступных рейсов на выбранную дату, а также post запросы на оформление заказа, его оплаты и возврата билетов.
Приложения для автогенерации документации.
Документация находится на поддомене docs.[cloud-b | poligon.cloud-b].ru
Раздел "Главное" формируется из main.md, остальные разделы из файлов .md в директориях приложений.
Из .md файлов формируются статические файлы .html (по команде create_docs), отдаются напрямую nginx`ом.
Иконки для разделов задаются в файле конфига icon_conf.json в директории приложения.
Приложение для выгрузки данных в Автоматизированную централизованную базу персональных данных о пассажирах и персонале ( экипаже) транспортных средств (АЦБПДП) в составе Единой государственной системы обеспечения транспортной безопасности ( ЕГИС ОТБ).
Общая информация , техническая документация.
Данные по пассажирам и рейсам регистрируются в модели DataEGIS, дальше регламентным заданием выгружаются на ftp сервера ЕГИСа.
Для выгрузки на сервера необходимо поднять защищенное соединение с помощью оборудования ViPNet координатор.
Существует тестовые сервера (параметры заданы в settings главного приложения), для них защищенное соединение не требуется.
Формирование файлов происходит в модуле process_v2 этого приложения.
Приложение для продаж билетов на терминале самообслуживания.
Своих моделей не содержит, работает на существующей инфраструктуре, реализует только специфичный интерфейс и представления для продаж билетов на терминале.
Почти все запросы, связанные с оформлением билетов обрабатывает представление SelectBase (внутри происходит роутинг на соответствующую функцию в зависимости от параметра запроса).
Приложения для продаж страховых полисов.
В модуле services определен абстрактный класс InsurerBase, для корректной работы нужно определить класс конкретного страховщика.
На данный момент реализован протокол взаимодействия с IBG (документация) и авибусом (документация).
Приложение для формирования отчетов по всей системе.
По старой версии, все отчеты запрашиваются в представлении ReportManager, где определен обработчик для конкретного отчета (со своим шаблоном).
В новой версии в модуле reports.py реализован абстрактный класс ReportBase. Конретные классы отчетов должны реализовать методы:
to_html - визуальное оформление отчета, которое пользователь видит на экране;
to_json - json представление отчета (для использование в стронних API);
to_excel - выгрузка отчета в эксель-файл.
Таким образом, отделяется методы выборки данных от их представления, что дает возможность представлять отчет в различных форматах без дублирования кода.
Для унификации представления отчета в HTML через универсальный шаблон simple_report.html, таблицу с заголовками и данными можно формировать также на беке.
Рекомендуется все новые отчеты реализовывать по новому формату, а также по возможности переписывать старые отчеты.
Приложение для фиксирования историй изменений по всем объектам.
Доработанное приложение auditlog.
Из глобальных доработок - модель LogEntry унаследована от CompanyRLS для разделения данных по компаниям.
Остальные незначительные доработки связаны с удобством вывода информации.
Приложение для логирования API запросов агентов по продаже билетов.
Доработанное приложение rest_framework_tracking.
На данный момент логируются только post запросы.
Приложения для выгрузки чеков в онлайн-кассу.
На данный момент реализовано API для взаимодействия с атол-онлайн (документация)
Из моделей только сама таблица с онлайн-чеками CheckOnline и логи запросов CheckOnlineLogs.
Методы API в модуле services.py.
Приложения для фиксирования обращений в тех. поддержку от пользователей ПО.
Clickhouse используется для разгрузки основной БД от редко используемых, но нужных данных (логов, историй изменений объектов и т.д).
Обычные django таблицы накапливают данные, все идентификаторы измененных объектов добавляются в redis, и дальше фоновым регламентным заданием одним большим массивом выгружаются в соответствующие таблицы в CH, после чего выгруженные данные удаляются из основной БД.
Приложения app, chat, dashboard, externalsale в настоящий момент не используются
Директория для хранения конфигов среды (nginx, supervisor и т.д), конфиги прокидываются в соответствующие папки через symlink.
Все необходимое для деплоя проекта.
Прочие полезные скрипты (взаимодействие с хранилищем яндекс-облака и т.д)