ChtoToTamNik

Так вот, в программу я взял лучшее из наработок в плане пользовательского интерфейса и старался совместить с наилучшими практиками которые нашел на просторах интернета.

В программе есть\будет:

• Личные чаты

  • Сообщения

  • Звонки

  • Анализ задач (автоматический поиск главных слов "Сегодня, сделай, завтра, посмотри, не забудь, т.д.) и создание автоматического TODO листа

• Канбан доска

  • Доска привязывается к задачам назначенным Вам или назначенные вами в Jira. И создает автоматически чат, добавляет туда "Автора" и "Исполнителя" если есть человек который подписался на отслеживание - тоже попадает в чат, либо можно добавить в ручную.

  • Статус чатов = статусам задач

• Серверы \ комнаты - аналог общих чатов в Discord и ТГ

  • Создание тем

  • Модерация прав

  • Группировка тем

  • Создание голосовых комнат

    • Общий звонок внутри комнаты

    • Демонстрация экрана

  • Создание темы "Тред"

    • Внутри лежат треды, нажимая на определенный тред можно попасть в комнату чата по треду. Это удобнее чем треды в MM которые создаются из простого сообщения.

  • Создание приглашений в группу

• Для чатов:

  • Полная поддержка PlantUml диаграмм с автоматической конвертацией в SVG. Можно описание посмотреть и картинку

  • Поддержка синтаксиса кода:

    • C++

    • Python

    • Go

    • Java

    • CSS

    • HTML

    • C#

    • PHP

    • JS

  • Поддержка MD формата текста (кто-то любит в таком писать, тем более поддерживает таблицы)

  • Пересыл сообщений

  • Закрепление

  • И много других дополнительных функций

• TODO лист задач

  • Создаются автоматически из контекста

  • Создаются вручную

• Отдельный сервис ботов

  • Преднастроенные будет только 3 бота и то для работы (в будущем возможно пораскину мозгами и придумаю действительно нужных для работы или общего пользования)

    • Уведомления о встрече из почты

    • Уведомление о GitLab изменениях при подписке на определенную ветку

    • Уведомления из Grafana об Alert-ах

Многое еще что в разработке и пока не раскрыто. Но в планах внедрить AI модель на BE для определенных задач.

Описана общая структура системы, но подробности я не описываю во всех красках...

Формат

Приложение имеет 2 формата для компаний и для личного использования.

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

Интерфейс так же меняется.

Для обычных пользователей не доступны функции TODO, Канбан доски, привязки к Jira или GitLab. Они им просто не нужны. Поэтому интерфейс немного отличается.

На архитектуре рисунок 1 - указано HTTP, почему так? Сейчас приложение развернуто в докере локально, мне тут не нужно дополнительное шифрование. Когда будет деплой (если будет) на сервер компании - в программе уже все готово к работе по HTTPS.

В чем плюсы приложения? Ему не нужен (МАХ). Все сообщения даже сейчас шифруются и дешифруются только на стороне клиента. Какие для этого использованы технологии - расскажу в сл. посте. Но сама суть в том что Дешифровать если получишь энкриптор получиться максимум один чат. Если пользователь решил переслать из одного чата в другой, то клиент выступает дешифратором и шифратором. Нагрузка есть, но минимальная, по моей задумке нагрузка в 2мс на сообщение из чата с 5к пользователями.

MongoDB для сообщений это временное решение. Мне было проще JSON модели делать и накидывать стиль. Позже она переедет в другую No SQL базу.

Что по звонкам? По звонкам интересно. По документации и оптимизации кода в моменте на комнату может быть 3к пользователей при условии 10 спикеров. Если будет 100 спикеров единомоментно - то 1.6-1.8к. Как будет в действительности покажет только практика. LiveKit почти не ест ресурсы и очень оптимально работает. Но кодек настраивать очень долго.

Защита от бутфорсов - имеется. Учтено сразу 2 формата:

• Единомоментный запрос в кол-ве Х

• Валидация кол-ва запросов с авто блокировкой последующих

Получается так, если злоумышленник захочет подобрать пароль и отправит 100 или 200 запросов в момент - они просто не пройдут шлюз. Он их не пропустит. Так еще и заберет 4 рандома и наложит ограничение.

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

K8s настроен. Предполагается, что основные сервисы работают на двух-трех чатах, а затем масштабируются в зависимости от нагрузки. Однако, если в чате менее 100 пользователей, одного сервиса хватит на 10–15 чатов. LiveKit масштабируется в зависимости от количества людей и комнат.

Что по ресурсам, сейчас приложение кушает около 450мб ОЗУ. Средняя латентность запросов 50-0мс и это на докере десктоп через WSL. По звуку - работаю над ним. Хочется сделать качественный шумодав.

Тестирование

Определимся с термином «хочу». В контексте разработки это означает «представляю». Я хочу запустить закрытое тестирование приложения на 500 человек в конце марта — середине апреля. Почему закрытое? Всё просто: аренда сервера для этого теста будет полностью за мой счёт, без спонсорской поддержки. Я планирую использовать виртуальный сервер с тарифом в районе 7–9 тысяч рублей (цены, конечно, кусаются).

Если сервер справится с нагрузкой в 500 пользователей и будет работать стабильно, я продолжу тестирование и расширю окно для пользователей. Если же возникнут проблемы, то придётся:

* Оптимизировать код.

* Поработать над улучшением запросов.

На данный момент у меня готовы две версии приложения:

* WEB.

* Windows.

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

Функционал в тестировании будет урезан примерно на 30% от фактически разработанного. Почему так? Некоторые фичи очень тяжелы в описании. Какие успею добить - залью на тест.

Опрос

Вообще много кому из знакомых показывал функционал и интерфейс - очень довольны. Плавность, логика - все есть. Нету ИИ-ых эмодзи (Я заменил их на прямую отрисовку в коде, вес приложения меньше, нагрузки практически нету). Острые углы от ИИ - тоже сглажены. Подправлена логика и получилось немного сократить код.

Что думаете? Жить проекту или не жить?)) Да, знаю есть куча заменителей и можно сказать "Очередная хрень под копирку". Но как показывает практика в нашей стране - все к чему у людей растет интерес рано или поздно блокируется... А приложений сделанных для людей а не для "маркетинга" - очень мало.

Нажимая на "Транспорт" открывается диалоговое окно, которое показывает полный список созданных типов транспорта и их вместимость.

Пользователь может:

1. Создать новый тип

2. Редактировать

3. Удалить

Окна создания и редактирования между собой похожи

При создании записи с данными в SQLite каждый пользователь, работающий с исходным файлом, видит изменения в своём интерфейсе.

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

В транспортной и складской логистике успешная транспортировка считается, когда процент утилизации трак стремится к 100%. Однако это редкое явление, так как часто перевозят воздух в коробках, а упаковка, например, стрейч, также влияет на утилизацию. Если же транспортировка осуществляется паллетами, то процент утилизации обычно ниже 85%.

С учётом этих факторов мы рассчитываем реальную стоимость перевозки. Например, трак объёмом 70 кубических метров стоит 300 тысяч рублей, а его утилизация составляет 90%. В этом случае перевозка одного кубического метра в среднем будет стоить 4,7 тысячи рублей. Различные цены на разные автомобили позволяют нам получить разные средние цены перевозки 1 кубического метра.

Как это работает. Пользователь выбирает склад, нажимает «Рисовать регион» и обводит на карте зону доставки. Затем он указывает типы автомобилей, которые могут использоваться для перевозки, и среднюю стоимость доставки одного кубического метра.

Эти данные попадают в расчёты «Анализ закрытия» и «Анализ открытия» (начал его разрабатывать).

Мы понимаем, что машина может следовать по рейсу, поэтому в отчёте программа автоматически рассчитывает рейсы. Но возникает вопрос: что делать, если машина утилизирована не полностью? Например, если товары для магазинов А и В попали в один маршрут, но их хватило только на 70% утилизации?

На этот случай тоже есть решение. Логика учитывает ближайшие объекты и дополняет рейс товарами для них. Если объём отгрузки небольшой, программа определяет оптимальный тип транспорта. В итоге мы получаем более-менее верное решение.

Данную логику сидел, проверял вручную в EXCEL и с помощью обычной карты. Попадание в 97% точности. Где-то не учла верность перераспределения и тем самым занизила на 3% стоимость перевозок. Но 3% (а вообще до 5%) в рамках погрешности, поэтому можно сказать что "Успех".

Доработка с транспортом - не сама тяжелая, она отняла у меня буквально 3 вечера.

Декомпозиция старого кода

Когда начинал писать программу, особо еще не знал правильность. Был такой юношеский максимализм. Писал огромные модули в одном файле, вследствие чего те же «Дашборды» разрослись на 5 файлов по 4к строк кода в каждом.

Сидел на прошлой неделе и думал: «Надо добавить пару новых графиков, а как делать-то? Я уже не помню этот код, куча вызовов, да и он больше на монолит похож». Пытался добавить спарку «График + гистограмма» — получил ошибку методов, начал ковырять глубже — так вообще пришлось откат из репозитория делать.

Новая структура выглядит более удобной, и можно вносить изменения с минимальными правками:

Для сравнения вот старая модель:

Это был настоящий кошмар. Стили, логика и подключения были объединены в один файл. Оркестратор "Менеджер" тоже содержал много лишнего..

UI — это то, что мы видим на экране. При любом взаимодействии с интерфейсом система вызывает посредника, который отправляет сигнал в логику. Логика получает сигнал и решает, нужно ли ей работать с хранилищем. Если да, она собирает данные и отправляет их обратно посреднику. Посредник проверяет, нет ли ошибок, и передает данные в UI, который их отображает.

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

В целом вообще сейчас стараюсь переписывать часть старого кода, с опытом многое понял про правильность и оптимизацию. Старые методы которые я писал с кучей подключений на 200-300 строк, получается сократить до 100-150. Первое - много принтов для логирования (часть убрал), второе - лишние проверки переменных. Добавлял на случай "Что бы на верняка".

Анализ открытия

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

На скриншоте выше - это только концепт-макет.

Накидал быстро файловую структуру которая будет для данного анализа.

По структуре видно что планируются такие логики как "Каннибализации". Это когда объект может забрать часть продажи у другого объекта

ROI с учетом всяких вводных типа "ФОТ, Аренда, опексы, стоимость транспортировки товара на магазин". Так как программа для компаний с большой историей, то и считать она будет исторические данные для точки. Например ближайшие магазины и какие продажи, какие тут были доставки и тп. Исходя из этого, строится предполагаемая модель продаж, выручка, считаются долгосрочные вложение и получаем сколько надо месяцев на окупаемость магазина.

Продуктовая матрица - как раз в ROI частично описал. Смотрим ближайшие магазины, смотрим что уходило в эту зону на доставку, считаем ABC, смотрит запас товара в регионе - формируем матрицу.

Логистическая карта - обратная функция от закрытия. Как измениться зона курьерских доставок и времени если именно тут открыть магазин.

И т.д.

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

Как обычно, всем спасибо за прочтение. Если есть какие-то идеи, предложения по улучшению UI или логики программы - пишите, буду рад принять что-то новое!😊

Следующие новости - после праздников. Всех с Наступающим Новым Годом!☃️

Сама карта — та же самая, что и была ранее, просто вместо 118 объектов теперь их всего 34, и собраны в одном городе.

Всем объектам была присвоена одинаковая товарная матрица и примерно одинаковые продажи, разница только в том, что один магазин, например, продавал «Сковороды» и у него этот сегмент А, другой продавал холодильники, которые так же попадают в А сегмент, но сковороды у него в С.

Зон доставок я сделал 5 вариантов, т. е. одинаковые зоны будут у 6 объектов, но это не критично, даже хорошо для проведения анализа.

Возьмем за пример объект с кодом ST_MSK_004 (магазин «Таганская»).

У него есть своя зона доставок, которая сложилась исторически.

Мемом выше можно понять, что зона не оптимизирована. Почему этот 004 магазин доставляет в зоны где тоже есть магазины? Загадка, а впрочем, и нет. Это же тест-данные. Я предположил, что, например, есть один объект, у которого каким-то странным образом падала основная часть доставок, и он отдавал сам курьерку. При этом магазин стал слишком мало приносить прибыли, и аренда взлетела, надо закрыть его.

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

Выбираем объект 004, ставим учитывать ABC-анализ и анализировать влияние на доставку клиентам и запускаем расчет.

Пока грузиться процесс, опишу что такое "Влияние на доставку".

У компании Х есть магазин, который они хотят закрыть, надо понять визуально, какое покрытие и кому отдать кусок от «пирога». Вот это как раз и делает программа. И в этом процессе закрылась основная проблема, с которой я долго боролся, на скрине выше, где показана зона, есть маленькие зеленые точки, это исторические данные, куда были произведены отправки. На их основе программа и строит полигональную сетку для визуализации. А как быть с пустыми местами? Вот она, основная проблема. Чуть позже вернемся к этому.

Как раз расчет завершен, предлагаю посмотреть труды.

Окно товарных запасов - визуально на табличном примере показываем фактический остаток товара в магазине

Ближайшие объекты - показывает то куда можно переместить товар, какое расстояние, емкость и доступность

План перераспределения — это уже предлагаемые распределения остатков с закрываемого объекта на ближайшие по следующей логике:

1. Проверяем товарную матрицу

2. Проводим АВС анализ (в будущем добавлю и XYZ)

3. Проверяем вместимость нового объекта

Если не подошло ни под одно действие, либо проверяем все найденные объекты в зоне, либо отправляем на склад, чуть-чуть логики с логов программы ниже:

Логи наверное скажут все за меня и гораздо больше)

Стоимость доставок - вообще должна считать по объему утилизации трака, сейчас как бы тоже (со скрипом) живой вариант, но есть уже накиданная логика, лежит под фичатоглом, надо проверять в будущем.

Влияние на регион - ничего интересного там нету, кейс без особенностей, программа говорит что все отлично

И вот она, та самая "Вишенка" на торте - влияние на доставку

Рассмотрим два типа карт: общая информация и данные о влиянии на время.

Информация о влиянии на время, как считает программа:

1. Смотрит 3 точки из текущей зоны доставки по закрываемому объекту:

   1. Самая дальняя точка по километражу

   2. Средняя точка

   3. Ближняя точка
      2. Считает время от объекта до каждой из этих точек и берет среднее арифметическое значение

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

Нажимая на "Синюю" кнопку открывается окно в котором при нажатии на пуск - происходит визуализация перераспределения зоны с учетом объектов и введенных параметров (Учет объектов вне зоны км). Состоит данный процесс из 5ти этапов.

1. Показываем закрываемый объект

2. Показываем все объекты которые находятся внутри текущей зоны и внешние согласно параметра.

3. Показываем фактическую зону доставок

4. Делим зоны на кластеры. И вот тут самое интересное.

Как сказать программе: «Смотри, есть вот такая зона, в ней есть 10, 15 или 20 объектов, подели рисунок на пропорциональные части с учетом оптимальной логистики?» А ведь внутри родительского кластера есть пустые зоны, в которых исторически не было доставок, а мы все равно должны их учесть и распределить.

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

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

Мы находим в начале объекты и рядом с объектами начинаем раскидывать точки с определенной плотностью.

Дальше мы показываем окончательный процесс (распределения кластеров и привязку их к другим объектам).

На примере одного из кластера. Есть магазин на Павелецкой, есть зона которая перейдет к нему.

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

Да и отдаленные магазины тоже правильно подхватили кластеры.

Какой же экстаз я словил когда руками проверил и убедился в том что да, все работает как и задумано. Как минимум этот процесс автоматизирован. Не надо теперь руками все это считать, собирать карты по крупицам. Работа которая занимает неделю а то и две может быть выполнена за 1 минуту. Это успех.

На моменте первой визуализации я думал: «Это успех», и лучше уже ничего не добавлять. Но потом пришла мысль, маленькая мысль, которая не давала покоя: «А что, если кому-то этого мало, а если надо показать визуально маршруты, точки из расчета?». Имея готовый скрипт JS и логику, мне просто потребовалось скопировать, вставить и дополнить первоначальный код.

Процесс анимирования занимает гораздо больше времени. Программе надо отправить API запрос, получить ответ, так для каждого объекта по 3 раза.

2025-12-15 16:08:02,800 - INFO - STDOUT - 🌍 Построение маршрута через OSRM (карта: yandex)

2025-12-15 16:08:02,800 - INFO - STDOUT - 🌐 OSRM API: попытка 1/2

2025-12-15 16:08:02,801 - DEBUG - urllib3.connectionpool - Starting new HTTP connection (1): 127.0.0.1:53913

2025-12-15 16:08:03,674 - DEBUG - urllib3.connectionpool - http://127.0.0.1:53913 "GET http://router.project-osrm.org/route/v1/driving/37.6215,55.7... HTTP/1.1" 200 682

2025-12-15 16:08:03,675 - INFO - STDOUT - ✅ Маршрут через OSRM: 0.9 км, 2 мин

2025-12-15 16:08:03,675 - INFO - STDOUT - ✅ Зона 21 добавлена: 1 маршрутов, 10 точек полигона

2025-12-15 16:08:03,675 - INFO - STDOUT - 🔍 Обработка зоны 22: facility=True, polygon=9, points=0

2025-12-15 16:08:03,675 - INFO - STDOUT - ⚠️ Зона 22: нет точек доставки, добавляем без маршрутов

2025-12-15 16:08:03,675 - INFO - STDOUT - ✅ Зона 22 добавлена: 0 маршрутов, 9 точек полигона

2025-12-15 16:08:03,675 - INFO - STDOUT - 🔍 Обработка зоны 23: facility=True, polygon=13, points=0

2025-12-15 16:08:03,675 - INFO - STDOUT - ⚠️ Зона 23: нет точек доставки, добавляем без маршрутов

2025-12-15 16:08:03,675 - INFO - STDOUT - ✅ Зона 23 добавлена: 0 маршрутов, 13 точек полигона

2025-12-15 16:08:03,675 - INFO - STDOUT - 🔍 Обработка зоны 24: facility=True, polygon=10, points=5

Лог работы построения маршрута.

Logistics_Analyzer - умеет работать с геодекодированием, но маршруты - извольте, я даже не знаю как их строить. Интересно было бы посмотреть как создается логика построения маршрута под капотом.

Итог:

Мы получаем кластер с тремя ключевыми точками и путями до них, включая полное описание маршрутов.

На третьем этапе программа последовательно демонстрирует каждый новый кластер и прокладывает маршруты (к сожалению, из-за ограничений медиа, я не могу приложить изображения).

Давайте подведем итоги кластеризации и перераспределения зон.

На мой взгляд, это успех. Конечно, есть некоторые недочеты, но они едва заметны и будут быстро исправлены. Логика работы выстроена, отчет динамичен. Теперь остается только проверить все на практике и собрать для него ОС от пользователей.

Есть план развития дальше, плюс устранение мелких недочетов. Первую бету версию планирую компилировать в начале марта 26г. Кому ее предлагать - это уже другой вопрос. Буду решать в момент возникновения.

В интерфейсе произошли некоторые изменения. Например, я перешел от скучной бежевой темы к более темным цветам. Часть стилей выделил в QSS и настроил их подключение в Main_window. Меню дашбордов стало напоминать Power BI с Excel, и были внесены другие мелкие правки.

Работаю над проектом по вечерам, уделяя этому 2-3 часа. Основные алгоритмы визуализации были написаны давно, но я долго не мог понять, в чем проблема. То данные распределялись неверно, то пробелы не учитывались. В начале реализации функции был у меня дата-файл, где зоны были более реалистичными, чем сейчас. При перераспределении их покрытие составляло всего 30%. То что "Ну очевидно можно сделать вот так" она делала "Тебе очевидно, а мне нет. Хочешь - делай сам".

Всем спасибо за прочтение. Пишите комментарии кто и что думает. Задавайте вопросы - отвечу)

• Доставка до клиента организована на уровне магазинов (не склада).

• Товарная матрица жёстко фиксирована: перемещение ассортимента между точками возможно только в рамках допустимых категорий (например, нельзя заменить «Телефоны» на «Хлеб» при перераспределении).

• Доступны фактические данные по:

  • продажам (с доставкой / без),

  • остаткам на точках,

  • SKU-уровню заказов с доставкой (включая адреса и объёмы).

На основе этих данных можно реализовать следующие аналитические и управленческие модули:

1. Определение зон покрытия магазинов
   По адресам доставок (без привязки к квартирам) и частоте заказов за период (например, за год) строится геопространственная область — зоны ответственности каждого магазина. Границы определяются экстремальными точками доставок.

2. ABC-анализ по SKU на уровне точки
   На основе фактических продаж формируется структура ассортимента: приоритетные, средние и низколиквидные SKU — с учётом оборачиваемости и вклада в выручку.

3. Моделирование альтернативного размещения при закрытии точки
   Сопоставление товарных матриц, зон покрытия и ABC-профилей позволяет идентифицировать подходящие точки-реципиенты для перераспределения остатков — с минимальными логистическими и коммерческими потерями.

4. Планирование перераспределения
   Комбинируя:

   • текущие остатки (на отправляющей точке),

   • лимиты хранения и нормативы по категориям (на принимающих точках),

   • совместимость товарных матриц,

   • пересечения зон покрытия и клиентской базы,
     формируется оптимальный план перемещения запасов — как при частичной реорганизации сети, так и при полном закрытии объекта.

Пример конфигурации:
Объект А характеризуется своей зоной покрытия и текущими остатками. Объекты Б, В, Г и др. — собственными остатками, ограничениями хранения по категориям, продажной динамикой и клиентскими зонами. Система оценивает все взаимодействия и предлагает планы по перераспределению товаров (Зон ожидается в будущем)

Компания Х решила закрыть объект А. Теперь нужно оценить, как это повлияет на:

- остатки товаров в других магазинах и на складе;

- зоны доставки других магазинов;

- среднее время доставки клиентам и стоимость перераспределения товарных остатков.

На основе этого анализа мы составим техническое задание для программы. Вот его основные пункты:

1. Определить регион, в котором находится объект А.

2. Выяснить фактические остатки товаров на этом объекте.

3. Найти ближайшие объекты с аналогичной товарной матрицей.

4. Провести ABC-анализ товаров на всех объектах за последний год.

5. Разработать план перераспределения товаров. Учитывать информацию из пунктов 1–3, а также средние затраты на перевозку одного кубического метра (задается при создании региона). Рассчитать оптимальное перераспределение.

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

Например, можно оперировать не стоимостью за километр, а средней себестоимостью перевозки на единицу объёма — скажем, при известных затратах в 1,5 млн ₽ на перевозку 160 м³ получаем удельную стоимость ~9,4 тыс. ₽/м³. (Цифра условная и приведена для иллюстрации.)

Более гибкий и масштабируемый подход — задать набор типов транспорта («траков») с атрибутами: тип маршрута, грузоподъёмность, объём и соответствующая средняя стоимость перевозки. Это позволит учитывать различия в логистике более точно.

С учётом этого, скорректирую модель и вернусь к дальнейшей проработке.

Программа, следуя установленным правилам, рассчитывает оптимальное размещение товаров. Если отключить АВС-анализ, она будет учитывать только остатки, местоположение и матрицу.

Ниже приведу пример работы данного функционала, данные заглушка и программа не может правильно разместить товары, поэтому все = 0.

P.S. Сейчас создание достоверных данных не является приоритетом.

Да, так как и писал - данные тестовые и в самом деле в регионе нет аналогичных матриц

Аналогично скрину выше, не нашли куда перевозить, доставка = 0.

И теперь основной вопрос "А что будет с доставкой? Как сильно закрытие повлияет на SLA по скорости?". Данный расчет сейчас является приоритетной доработкой которой я занимаюсь.
Логика которая мною вкладывает в анализ - следующая:

1. Смотреть на расстояние различных точек на карте

2. Делить действующую зону на кластеры

3. Определить оптимальные объекты по времени которые находятся рядом

4. Сделать ренден всех 3-ех пунктов и показывать изменения в зонировании доставки с отчетом об изменении среднего времени и какие районы слишком далеко.

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

Функция выбора источника данных для программы и совместная работа с одним исполняемым файлом.

В параллели с влиянием на регион, мне удалось внести не большую доработку в систему. Теперь пользователи могут выбирать исполняемый файл.

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

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

После отправки - логи приходят ко мне в ТГ через бота. Все логи запаковываются в zip архив, параллельно запускает процесс удаления логов из папки.

Почему я быстрее реализовал совместный доступ и отправку логов, вместо того что бы наполнить данными и показать на примере где все логично? Наверное потому что лень тратить много времени на создание данных, а потом их дополнять и править. Программа не окончательная, система хранения меняется. Например сейчас я понял что стоимость доставки и распределения товара можно завязать на типы траков - буду реализовывать и менять хранение. Менее затратно по времени дописать скрипт, чем создавать новую логику в 1000 строк данных.

Всем спасибо за то что дочитали.

Если есть желание предоставить тестовые данные с логикой - буду очень рад, поможет при тестировании. Шаблон данных могу предоставить.

P.S. Такие случаи встречаются довольно часто, особенно когда компании чрезмерно увеличивают штат сотрудников.

Как упростить эту модель? Программа не является WebView, она десктопная, не имеет серверов и хранит данные локально. "Решение есть!" — скажу я вам. Виджет панель с сохранением состояний в JSON. Получаем универсальную настройку программа у каждого пользователя, но работающего с одной системой.

Включая правую панель с виджетами, мы можем выбрать преднастроенные карточки, либо добавлять свои карточки на дашборды.

Что бы добавить новый виджет или выключить существующий необходимо просто прожать чекбокс.

А состояние мы просто сохраним в JSON формате.

Нажатие на "Добавить ссылку на дашборд" запускает процесс получения данных из системы. Получается компонент опрашивает БД через отдельное ядро "Есть ли у нас созданные дашборды? Да? Верни название страницы, я создам список для пользователя"

Код ответил "Да, у нас есть страница с названием (Тестовый шаблон)", далее дроп окно нам показывает название и имеет возможность выбора из нескольких вариантов.
Для удобства настройки - предоставлена возможность выбор иконки для виджета и создания названия виджета.

Вот мы добавили новый тип виджета "Ссылка на дашборды".

При нажатии на элемент виджета программа перенаправит нас на страницу с настроенными графиками и информацией, которые так же настроил пользователь.

Если сравнить с предыдущим постом, видно, что окно с графиком изменилось. Это правильно, ведь для настройки через аналитический куб доступно меню редактирования. В этом режиме пользователь может добавить страницу, новый график или фильтр. Также можно настроить DAX-поле и провести расчеты по нему.

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

Ах, да. Говоря о возможностях правой панели, я потерял нить: "Как же это улучшит работу?".

Программа использует переменную, позволяющую выбрать между локальным хранилищем SQLite3 и сетевым. Это обеспечивает совместную работу всех пользователей с одними данными и возможность добавления новых. Человек ИКС настроил скрипты для получения данных, подходящих под программу. Другие пользователи могут не только просматривать наборы кириллицы и латиницы, но и визуализировать данные на карте с интерактивным просмотром. Они также могут создавать свои собственные графики и дашборды.

Хотя я не претендую на замену BI-систем, я понимаю, что не у всех есть средства для внедрения полноценных аналитических систем. JSON структура позволяет настроить уникальный формат панели в соответствии с предпочтениями пользователя.

Чрезмерно благодарен за уделенное время прочтения статьи. Впереди третья часть в следующую среду)

P.S. Местами есть разногласия в теме дизайна, активно перевожу на централизованный QSS стиль темы. Это позволит изменять один файл и менять тему везде. Сейчас частично стили интегрированы в код

Спустя время мы конечно закрыли проект со всеми расчетами, применили изменения. Но только вдумайтесь, целый департамент на протяжении пары месяцев считает рентабельность изменения целой инфраструктуры и влияние на него всего лишь закрытием 1-2 объектами. Это колоссальные затраты для компании.

Со временем я перешел в IT, сменил свою сферу деятельности, в свободное время изучал различные языки программирования, фреймворки и понял "А что если разработать аналог для логистической инфраструктуры. Да, конечно дизайн будет не броский, но нам важна лишь функциональность и работоспособность данной программы". Соответственно в начале 25г мною было принято решение начать разработку. Как раз время AI инструментов, не идеальные, но какие-то нюансы они могут подтянуть что бы не лезть в тех доку на изучение той или иной функции/метода/условия.

Язык: Python.

Библиотеки для интерфейса: PyQt6.

Хранилище всей информации: SQLite3.

Частично использовалось: HTML, JS.

И множество второстепенных библиотек для кодирования информации, реализации возможности подключения внешних БД, работы с таблицами и т.п.

Python — язык не самый лучший, да и PyQt библиотека своеобразная и довольно хорошо нагружает систему, сама программа начинает весить тоже немало. Но ведь мы не гонимся за «вау-эффектом».

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

«Оптимизации доставок», «1С:Транспорт», «SAP», «Транспортный анализ» и т.п. Но ни одной подходящей под мое описание программы не было.

Что включало в себя мое виденье всей системы:

1. Интерактивная карта с маркерами объектов.

2. Автоматический расчет зонирования регионов в зависимости от исторических данных продаж с доставками.

3. Отображение линий снабжения объекта прям на карте в формате «Объект А -> Объект Б -> Объект С».

4. Планирование маршрута при выборе определенных объектов.

5. Возможность построение интерактивных дашбордов.

6. Возможность создание различных интерактивных виджетов и их настройка.

7. Внутренний аналитический куб.

8. Подключение к внешним БД как к источнику данных и тонкая настройка самим пользователем с маппингом полей.

9. Создание регионов по складам (ручное выделение самого региона на карте).

И прочие функции, по типу DAX-языка при создании вычислительных полей.

Вишенка на торте всей программы:

10. Анализ инфраструктуры автоматически на ядре программы в формате «Что если?».

А что, если мы закроем магазин на Савеловской — как это повлияет на зону доставок ближайших магазинов/складов. А куда перевозить товар? Сколько машин надо и какая утилизация будет? А какие магазины есть в регионе? А что будет с инфраструктурой, если мы закроем целый склад? Кто теперь будет снабжать товаром магазины? А какая матрица товара есть сейчас? Как изменится структура поставок от основного склада на магазин, будем ли мы задействовать транзитные склады?

Первое, что я начал делать — накидывать БД, да, мы не имеем сервера, поэтому нам надо хранить данные для работы программы локально. Почему не сделать под клиента? Ну-у-у... Возможно, потому что у всех своя структура хранения, а аналитики есть везде, написать SQL-запрос и выгрузить данные по шаблону куда проще, чем делать программу с адаптивом. Имея опыт в работе с логистикой и инфраструктурой, я понимал, какая +- система хранения у всех компаний, труда собрать хранение мне не составило.

Вторым моим шагом стало изолирование всех действий с БД в программе. Т.е. все методы программы не должны общаться на прямую с хранением, а ходить через выделенный файл (ресурс).

Третий шаг — создание интерфейса, вкладок, виджетов и т.д. Можно было сделать через WebView, писать отдельно файлы форм, настраивать JS-логику, передавать сигналы в .py-файлы и т.д. Но это слишком усложняет весь проект, расширяя его код. В таком случае один я уже не смог бы вывести. Поэтому выбрал PyQt6. Долго анализировал, как лучше сделать, но ничего умнее не придумал. Так и родился первый интерфейс программы:

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

Четвертый шаг — создание ядра всего мыслительного процесса, пользователь нажал на кнопку, а что дальше? Дальше как раз таки отдельные компоненты, которые получают запрос и идут по логике дальше, забирают/обновляют/удаляют данные через шаг 2, интерпретируют их и отдают ответы на модули, которые вызывали.

Да, конечно, с ядром программы я возился довольно долго. Ввиду того что это не 1С, а свой, по сути, уникальный продукт, мне на 80% удалось создать полный конструктор ядра. Что это значит? Значит то, что всю дальнейшую логику мне надо лишь описывать в исполняемых файлах core. Это дало прирост к написанию более качественного кода, более чистого. Да, репозиторий программы увеличился с 15 mvp файлов до 80. Отдельный исполняемый файл практически на каждую форму и отдельно логический файл. Зато мы сразу имеем максимально декомпозированную структуру, которую легко править и изменять процессы.

Далее было много различных шагов, криптография подключения к БД, логирование действий для отслеживания ошибок программы, перевод карты на формат HTML+JS. Получение API ключей и т.д.

В последний момент я задался вопросом: «Как распространять обновления программы? Ведь если я внесу новые правки — пользователь должен их получить. Также я должен делать логирование для использования программы».

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

Интерфейс для лаунчера я накидал быстро с помощью нейронки, вручную написал код для авторизации на js с py. Настроил всё и протестировал. И «О чудо!» не имея большого бюджета у меня получилось реализовать это всё, над безопасностью авторизации еще, безусловно, стоит потрудиться.

Через некоторое время написал тест кейсы, написал алгоритм для тестирования всех модулей, поправил баги, которые вызывали сбои. Сейчас готова версия 0.5.8. До релиза v1.0.0 еще далеко, много разделов, которые моя голова хочет реализовать.

Что делать дальше? Когда я только начинал, был уверен, что проект можно продать. Я видел такие кейсы и раньше. Думал, что смогу развивать его сам, возможно, еще на год разработки в свободное время меня хватит, и я не погрязну во всей архитектуре. Но год спустя сомнения все чаще берут верх. Может, я зря трачу время?

Возможно, данным постом я смогу найти тех, кого воодушевит мой проект или просто он кому-то приглянется. А возможно, просто получу дельные советы.

Если у вас есть идея и желание реализовать её самостоятельно, смело действуйте.

В скором времени постараюсь выложить еще пост о новых функциях программы.

Делитесь своими комментариями и мнениями.