| Загрузка... |
| Группа | Пункт назначения | До 20 кг, ₽ | Доп. кг, ₽ | Дни доставки | Сноска |
|---|
| Каноническое имя | Район | Зона | Алиасы | Партнёры |
|---|
| Время | Отправитель | Тема | Авто-класс | Решение | Статус | Накладные |
|---|---|---|---|---|---|---|
| Нажмите «Обновить» | ||||||
| Дата забора / создано |
Отправитель | Телефон | Адрес забора | Город | Тариф | Статус | Источник | KD-номер |
|---|---|---|---|---|---|---|---|---|
| Нажмите «Обновить» | ||||||||
| ИНН | Название (canonical) | ОПФ | Город | Роли | Активность | Последний контакт |
|---|---|---|---|---|---|---|
| Нажмите «Обновить» | ||||||
| Время | Пользователь | Действие | Накладная | Детали | IP |
|---|---|---|---|---|---|
| Нажмите «Обновить» | |||||
Войдите в систему
Введите номер накладной из базы — Claude попробует определить её группу по текущим правилам.
Обрабатывает до 50 накладных без группы — Claude определит группу по текущим правилам.
Это карта системы простыми словами: откуда приходят документы, что с ними происходит, где они хранятся и как принимаются решения.
Технических подробностей здесь нет — только логика работы. Если что-то поменялось в поведении системы, обновите эту страницу.
Система собирает документы о посылках из разных источников, приводит их к единому виду, хранит в одной базе и отдаёт наружу — в виде интерфейса, отчётов и архива на Яндекс.Диске.
Всё держится на одном принципе: единый источник правды — это база данных. Файлы на Яндекс.Диске, отчёты, выгрузки — это «слепки», которые формируются из базы, а не наоборот.
Документы приходят тремя путями. Каждый ведёт к одному и тому же месту в базе, но по-своему.
Почтовый ящик проверяется автоматически каждые несколько минут. Каждое новое письмо сначала сортируется на один из трёх типов — манифест, заявка на забор или прочее — и в зависимости от типа либо разбирается автоматически, либо отправляется оператору на ручную проверку.
Накладная — это запись об одном отправлении. Вот её жизненный путь.
Одна накладная может прийти дважды — сначала таблицей-реестром, потом фотографией расписки. Чтобы не плодить дубликаты, запись опознаётся по сочетанию: номер накладной + группа + год + месяц.
Перед разбором система определяет тип изображения и дальше использует подходящий способ чтения. Накладная — это документ об отправлении; расписка — подтверждение получения.
Каждое письмо относится к одному из типов:
«Группа» — это принадлежность накладной к конкретному партнёру или перевозчику (например, Major Express, Кинетика). От группы зависят тарифы и отчёты. Откуда она берётся — по убыванию частоты:
Статус показывает, на каком этапе находится отправление.
не доставлено / в работе доставлено забрано просрочено аннулирована
Расписка — это подтверждение получения груза. Основной путь сегодня: курьер сам выбирает накладную или заявку в приложении и прикрепляет к ней фото — расписка гарантированно попадает к нужной записи. Фото при этом всё равно читается автоматикой: из него берутся отметка о доставке, дата и рукописная фамилия получателя.
Запасной путь — загрузить «просто фото» (например, в Telegram): тогда система сама распознаёт номер и ищет накладную по текущему и двум предыдущим месяцам — расписку часто загружают с задержкой.
Заявка на забор — это просьба партнёра приехать и забрать груз. Она живёт отдельно от накладных, потому что у неё другая жизнь: время «с/по», адрес забора, своё содержимое.
Когда сортировщик писем уверен, заявка заводится полностью автоматически. Оператору уходят только сомнительные письма и письма, из которых не удалось извлечь данные, — молча ничего не теряется.
Статусы заявки: открыта связана закрыта отменена не смогли связаться просрочена
Один и тот же клиент в разных документах пишется по-разному («АО АбИнБев Эфес», «АбИнБев», «Эфес»). Чтобы это был один клиент, ведётся единый справочник. Каждый встреченный отправитель/получатель приводится к канонической записи с ИНН.
Как система понимает, что это тот же клиент (по порядку):
При повторной встрече к существующему клиенту просто добавляются новые варианты написания, телефоны и роли — ничего не теряется.
Города ведутся отдельным списком с регионом и вариантами написания. Он нужен, чтобы понимать, относится ли точка к Красноярскому краю (признак «в зоне»), и чтобы сопоставлять обрезанные распознаванием названия («Зеленогорск(Кра») с правильными.
База данных — главный и единственный источник правды. Яндекс.Диск — это витрина и архив, которые формируются из базы:
Из базы можно собрать помесячный счёт партнёру (реализован для Major Express). В отчёт попадают только отработанные отправления выбранного месяца.
Каждая строка делится на два типа по тому, где находится «крайняя точка в Красноярском крае»:
Имя клиента в отчёте берётся из единого справочника (чтобы не было разнобоя), тариф — из таблицы расценок по нормализованному названию города.
Помимо помесячного счёта, система сама рассылает регулярные сводки: вечерний отчёт дня в Telegram (19:00), ежедневные отчёты по Major Express и Кинетике на электронную почту (19:30), понедельничную сводку аномалий почты (09:00) и ночную сводку распознаваний (04:30, см. следующий раздел).
Дневной отчёт можно переотправить вручную за любой день — из раздела «Почта» на сайте или с вкладки «Все накладные» в мобильном приложении. В приложении перед отправкой отчёт можно проверить: кнопка разворачивает ленту с теми же строками, что уйдут в письмо, — приёмки и доставки с номерами заявок и накладных, получателями, курьером и фотографией каждой накладной. Накладные без фото помечаются предупреждением (они попадут в таблицу письма, но не в фотоархив). Если при сверке нашлось несоответствие, группу и статус накладной можно поправить прямо в ленте — правка сохраняется сразу и попадает в историю изменений; карточка помечается «в этот отчёт уже не попадёт». Кнопка «Проверено — отправить» внизу ленты отправляет отчёт без лишних вопросов.
Система записывает не только сами данные, но и то, как они менялись и как автоматика принимала решения.
Зачем это нужно: по накопленной статистике видно, каким методам можно доверять больше, а где ИИ со временем можно заменить простыми правилами. Разметка для этого копится сама, как побочный продукт обычной работы, — никого не нужно просить размечать данные вручную.
Кнопка «✦» на сайте (справа внизу) и на главном экране мобильного приложения — только для администраторов.
Помощник отвечает на вопросы о работе системы двумя способами:
Что именно хранится в базе. Названия даны для справки — в работе они скрыты за интерфейсом.
| Таблица | Что хранит | Ключевое правило |
|---|---|---|
| nakladnye Накладные | Все отправления: номера, города, получатель, оплата, вес, статус доставки, дата, ссылка на фото расписки, признак архива. | Уникальна по номеру + группе + году + месяцу. Доставку нельзя «откатить». |
| pickup_orders Заявки на забор | Просьбы приехать за грузом: адрес и время забора, вложение, признак «в зоне», подсказанная и подтверждённая связь с доставкой. | Живут отдельно от накладных. Уникальны по своему номеру. |
| counterparties Клиенты | Единый справочник юр.лиц, ИП и частных лиц: каноническое имя, ИНН, псевдонимы, телефоны, роли. | Один клиент = одна запись; дубли сливаются. Уникальность по ИНН. |
| cities Города | Справочник городов: регион, варианты написания. | Определяет признак «в зоне» (Красноярский край). |
| prices Расценки | Тарифы по направлениям и группам, с периодом действия. | Версионируются датами «действует с / по». |
| Таблица | Что хранит |
|---|---|
| email_classification | Состояние разбора каждого письма: какой тип определён, обработано ли, когда уведомляли оператора. |
| email_imports | Связь «письмо → созданная накладная или заявка». Гарантирует, что у каждого импорта есть след. |
| address_normalize_cache party_normalize_cache | Запомненные ответы внешнего справочника по адресам и организациям — чтобы не спрашивать одно и то же дважды. Можно безопасно очистить. |
| kd_number_seq | Счётчик номеров для веб-заказов (вид KD-ГОД-НОМЕР). |
| Таблица | Что хранит |
|---|---|
| users | Пользователи системы и их роли (администратор, суперадминистратор, курьер). |
| action_log | Журнал действий: кто, что и когда сделал — для разбора инцидентов. |
| история_изменений | По-полевая история правок накладных и заявок: что было → что стало, кто и откуда. Пишется самой базой, поэтому видит даже ручные правки мимо приложения. |
| распознавания | Журнал ответов автоматики: задача, метод, ответ, уверенность. Основа ночной сводки точности. |
| group_hints | Правила определения группы со вкладки «Группы» — словесные описания бланков для Claude. |
| receipt_examples | Удачно распознанные расписки — показываются ИИ как примеры при чтении следующих фото. |
| courier_zones | Зоны обслуживания курьеров: какой курьер возит в какой город, дни и сроки доставки. |
| roadmap_tasks | Задачи вкладки «Задачи» (дорожная карта развития системы). |
| schema_migrations | Технический список применённых изменений структуры базы. |
| Термин | Что это |
|---|---|
| Накладная | Запись об одном отправлении — основная единица в системе. |
| Манифест / реестр | Таблица со списком отправлений от партнёра (приходит файлом или письмом). |
| Расписка | Подтверждение получения груза; обычно фото от курьера. |
| Заявка на забор | Просьба партнёра приехать и забрать груз. |
| Группа | Принадлежность накладной к партнёру/перевозчику; влияет на тарифы и отчёты. |
| Клиент (контрагент) | Отправитель или получатель из единого справочника. |
| Канонический номер | Номер накладной без пробелов и дефисов — для надёжного сопоставления. |
| В зоне | Признак, что точка находится в Красноярском крае. |
| Черновик накладной | Накладная, создаваемая автоматически, когда курьер прикрепляет фото груза к заявке на забор; именно она связывает заявку с доставкой. |
| История изменений | Журнал «что было → что стало» по каждому полю; пишется самой базой и видит даже правки мимо приложения. |
| Журнал распознаваний | Записанные ответы автоматики с методом и уверенностью; из него ночная сводка считает точность. |
| Архив | Старые записи, спрятанные из обычных списков. |
Эта страница — обзор логики системы для операторов. Технические детали и регламенты — в служебной документации проекта.