Заявки и отправления

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

Заявка отвечает на вопрос «что мы приняли»: заказчик, груз, направление, условия расчёта. Отправление отвечает на вопрос «чем везём»: маршрут, этапы, перевозчики, транспорт, сроки. Одно отправление может закрывать несколько заявок: сборный груз так и работает.

Связь между ними видна с обеих сторон: из заявки — в отправление, из отправления — в список заявок, которые оно везёт.

Заявленные вес, объём и количество мест вносит менеджер со слов клиента при создании заявки. Фактические фиксирует склад при приёмке.

Рабочий цикл выглядит так:

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

Расхождение «заявлено / фактически» видно сразу и не требует сверки. На нём и строится разговор с заказчиком, и хорошо, когда он идёт с числами, а не по памяти.

Поле «Тариф» — это ставка, по которой груз принят. При выборе тарифа система замораживает его условия в самой заявке: ставку, валюту, единицу измерения, «за количество», настройку объёмного веса и дату применения.

Поэтому в карточке видно не только название, но и строку условий целиком, например «3,50 EUR / 1 кг, объёмный вес 150 кг/м³, применён 10.08.2026».

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

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

Наборы статусов настраиваются под компанию: свои названия, свой порядок, свои признаки «по умолчанию» и «финальный». Из коробки идут разумные наборы, но они именно стартовые.

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

Документы прикрепляются к заявке и к отправлению, а не лежат в почте у того, кто их получил. Доступ к файлу проверяется правами: сотрудник склада, менеджер и заказчик видят разное.

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

Две оговорки, без которых таблица вводит в заблуждение:

• Один запрос на загрузку ограничен 50 МБ. Поэтому архив крупнее пятидесяти мегабайт до системы не доедет, хотя по типу ему разрешено сто.
• У электронной транспортной накладной лимит свой и более жёсткий: его ставит оператор, а не мы, до 20 вложений и 20 МБ суммарно на накладную. См. ЭТрН и ЭДО.

Общий объём хранилища зависит от плана подписки, см. тарифы.

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

Колонка «Счёт» показывает состояние расчётов индикатором, а суммы счетов и долг стоят рядом: так виден не только логистический, но и денежный статус перевозки. Подробнее об этом на странице финансов и взаиморасчётов.

• Не строим маршруты и не считаем расход топлива

  Маршрутизация и телематика — отдельный класс систем. LogiFlow ведёт учёт перевозки, а не управляет движением машины по карте.

• Не заменяем CRM

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

• Не переносим данные из другой системы автоматически

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