Как сверить заявку, транспортную накладную и акт по одному рейсу

Рейс выполнен, но закрывать его рано: в заявке один адрес разгрузки, в накладной другой, а акт составлен по первоначальным условиям. Документалисту нужно понять, что именно изменилось, кто подтвердил изменение и какой документ теперь считать верным. Если поток рейсов растёт, такая сверка отнимает время не из-за сложности одного файла, а из-за поиска последней согласованной версии среди писем, таблиц и учётной системы.

Как документы одного рейса расходятся между собой

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

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

Поэтому сверку транспортных документов полезно рассматривать как отдельный этап закрытия рейса. Вход — комплект источников. Выход — реестр совпадений, расхождений и недостающих подтверждений. Решение по каждому спорному пункту остаётся у сотрудника.

Какие источники и версии собрать сначала

Начните с идентификатора рейса или заказа. Он должен связывать документы в TMS, 1С, почте и папке с файлами. Если идентификатора нет во всех источниках, заранее определите, по каким реквизитам сотрудник устанавливает связь: номер заявки, контрагент, маршрут, дата, внутренний номер перевозки. Совпадения только по дате или имени клиента может быть недостаточно.

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

Если TMS или 1С хранит утверждённые поля в структурированном виде, используйте их как один из источников. Не нужно повторно распознавать то, что система уже знает. Но и запись в учётной системе не следует автоматически считать верной: проверьте, кто и на основании чего её обновил. Для процессов между системами отдельно описан перенос и сверка данных.

Какие данные сопоставлять по регламенту компании

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

Условный фрагмент реестра одного рейса:

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

Полезно хранить не только итог «совпадает/не совпадает», но и ссылку на строку, поле или сообщение, из которого взято каждое значение. Тогда сотрудник может быстро перепроверить вывод. Без ссылок реестр превращается в ещё одну таблицу, которой приходится верить на слово.

Как агент готовит реестр расхождений

Агент получает комплект, связывает файлы с рейсом и выделяет значения по утверждённому перечню полей. Затем он сравнивает их с подтверждёнными данными TMS или 1С и между документами. Результат — черновик реестра: какое поле отличается, в каких версиях, откуда взяты значения и чего не хватает для решения.

Там, где документы структурированы и правила однозначны, лучше использовать обычную проверку в учётной системе или скрипт. Агент полезен, когда условия и подтверждения разбросаны по письмам и разным форматам файлов. Даже здесь он не должен угадывать отсутствующие условия. Если источник нечитаем или версия спорна, он отмечает это и передаёт вопрос человеку. Именно на таких входящих материалах жёсткий сценарий RPA может остановиться.

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

Что проверяет и подтверждает человек

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

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

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

С чего начать проверку своего потока

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

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