При оптовой или розничной торговле алкогольной продукцией часто возникает критически важный вопрос: как грузоотправителю оперативно и достоверно узнать, что отправленная товарно-транспортная накладная (ТТН) успешно доставлена до Универсального транспортного модуля (УТМ) получателя и подтверждена им? Проанализируем эту ситуацию по шагам, разберем логику работы обмена с ЕГАИС и выясним, какими запросами и документами можно отследить статус накладной.
Для начала разберем по шагам, какой путь проходит накладная и какую обратную связь мы можем получить в своем УТМ как отправители. ЕГАИС работает по принципу асинхронного обмена документами. Это означает, что мы не получаем мгновенного ответа о статусе накладной у клиента.
Рассмотрим этапы прохождения документа:
Многие пользователи и разработчики сталкиваются с проблемой: накладная отправлена, клиент по телефону говорит, что все подтвердил, а в программе статус не меняется. Выясним причину на уровне архитектуры ЕГАИС.
Когда грузополучатель подтверждает получение, он генерирует документ типа WaybillAct. Если этот документ отправлен покупателем, он обязательно прилетит грузоотправителю в рамках стандартного обмена ЕГАИС. В этом акте указывается согласие с приемкой товара.
Если грузополучатель принимает товар с расхождениями, он формирует акт разногласий. В этом случае грузоотправитель, получив такой акт, должен отправить в ответ документ ConfirmTicket на этот WaybillAct. Внутри данного тикета в поле IsConfirm указывается, согласен ли отправитель с выявленными расхождениями или нет.
Частая ошибка при разработке или настройке интерфейсов: входящие документы типа WaybillAct могут быть программно отфильтрованы и не отображаться в списке входящих сообщений пользователя, "чтобы не занимать голову оператора". Если вы не видите подтверждений, обязательно проверьте сырые XML-ответы в папке IN вашего УТМ. Посмотрим на пример структуры обмена, с которой приходится работать программистам при разборе XML-схем ЕГАИС (на примере классификатора пива):
<xs:element name="TypeBeer" nillable="false" minOccurs="0" maxOccurs="1">
<xs:annotation>
<xs:documentation>Тип пива</xs:documentation>
</xs:annotation>
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:maxLength value="50"/>
<xs:enumeration value="светлое"/>
<xs:enumeration value="темное"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
Поскольку УТМ не информирует нас о том, забрал ли клиент накладную (этап 2), для точной диагностики зависших документов мы должны использовать специальный сервис проверки ФСРАР. Рассмотрим, как это работает.
Проверка осуществляется по двум ключевым параметрам:
В современных реалиях ручная проверка через браузер отходит на второй план. Разберем автоматизацию этого процесса.
В современных конфигурациях 1С процесс контроля статусов максимально автоматизирован. Вам не нужно вручную искать WaybillAct в логах.
Для автоматизации используются РегламентныеЗадания. Система самостоятельно с заданной периодичностью опрашивает УТМ. Когда во входящих сообщениях обнаруживается акт от клиента, 1С парсит XML-файл, связывает его с исходной исходящей ТТН по внутреннему идентификатору и меняет статус документа в интерфейсе пользователя на "Подтверждено", "Отклонено" или "Ошибка доставки".
Более того, для проверки факта доставки до УТМ клиента, существуют встроенные обработки (или внешние расширения), которые по API отправляют POST-запросы к сервису проверки ФСРАР напрямую из 1С. Для этого система использует сохраненный FSRAR_ID контрагента и внутренний номер транспортного пакета, выводя актуальный статус прямо в форму списка ТТН.
Проанализируем ситуации, когда стандартный процесс нарушается, и рассмотрим инструменты для их решения.
1. Ошибка в отправленной ТТН до подтверждения.
Если вы отправили накладную, но поняли, что совершили ошибку (например, неверное количество или цена), а грузополучатель еще не подтвердил её, вы можете отозвать документ. Для этого из вашей системы в УТМ отправляется специальный запрос на отмену — RequestRepealWB. ТТН будет аннулирована, и вам не придется ждать акта отказа от клиента.
2. ТТН "потерялась" у клиента.
Иногда грузополучатель заявляет, что не видит накладную в своей учетной системе, хотя по данным ЕГАИС она была доставлена в его УТМ. Такое случается при сбоях локальной базы данных или случайном удалении входящих XML-файлов до их обработки. В этом случае грузополучатель должен воспользоваться функцией "Повторный запрос неподтвержденных накладных". Отправив запрос в ЕГАИС по своему FSRAR_ID, он получит список всех ожидающих ответа ТТН. После этого документы будут повторно выгружены в его УТМ для загрузки в 1С и последующего формирования акта подтверждения.
3. Сроки обработки актов расхождений.
Важно помнить: если клиент прислал акт приемки с расхождениями, мяч на вашей стороне. Если вы не отправите ConfirmTicket (согласие или отказ) через свой УТМ в регламентированный срок (обычно это несколько рабочих дней), система ЕГАИС может автоматически провести операцию по версии грузополучателя. Поэтому регулярный фоновый обмен с УТМ критически важен для бизнеса.
Резюмируя: статус ТТН в ЕГАИС — это не статичное поле, а результат обмена асинхронными XML-документами. Грузоотправитель узнает о подтверждении только тогда, когда УТМ скачает входящий документ WaybillAct от клиента, а для промежуточного контроля доставки следует использовать сервисы проверки ФСРАР, интегрированные в вашу учетную систему.