Отмена ТТН и уведомление об этом, повтор актов, перезапрос документов

[antonn]

Добрый день.
Хочу прояснить ситуации, жду ответов операторов. Пока ответа не будет - тему буду подымать до упора, ибо задолбало что навязываемая система не имеет документации и обратной связи, но при этом имеет характер обязаловки и расплачивается бизнес уже реальными штрафами.
Итак.
1. Повторно высылаемая поставщиком ТТН. Повторно высылаемая ТТН - это связка полей "дата доставки", ИИН поставщика (или clientregid), number.
a. Есть ли еще какие-то другие обязательные поля для однозначной идентификации ТТН?
b. Допустима ли повторная отправка поставщиком ТТН с этими (и другими) одинаковыми полями? Что получит адресат, две ТТН и две справки? 22 января нам до сих пор аукается.
c. Допустимо ли поставщику отправлять ту же ТТН с измененным полем [ShippingDate]?

2. Отмена ТТН со стороны поставщика.
a. Какие документы приходят к адресату в УТМ в случае отмены поставщиком ТТН?
b. При каких состояниях ТТН они могут быть отменены (например при отсутствия акта подтверждение или наличия только акта расхождения)?
c. Каким образом получить номер ТТН, если на отправленный акт приходит тикет отказа с текстом "Поставщик оформил новую версию данной ТТН. Подтверждение или отказ требуется для ТТН с рег. ид.: TTN-******** Владелец [*****]."? Полагаю выдирать номер из этого комментария свободной формы не самая удачная затея, могу ли я в структуре тикета получить номер ТТН на который мне теперь необходимо оформить акт?
d. В чем функциональное различие документов WayBillTicket и Ticket? По поводу WayBillTicket я делал тему, ответа в ней так и не дождался ( viewtopic.php?f=2&t=2150 ).

3. Потенциальные ошибки при работе служб обмена данными.
a. Что делать когда в УТМ пришел документ waybill, но нет FORMBREGINFO? Причем прошло довольно много времени (например, неделя). Каким образом я могу автоматизировано запросить повторную отправку в мой УТМ этих данных? При этом поставщик получил квитанцию и может сказать номер фиксации (с мой стороны это никак не важно, мне надо все автоматом только со своей стороны).
b. Нет ответа от поставщика на акт, хотя сам поставщик клянется что отправлял (в opt/int документ зафиксировался, в opt/out я его нкиогда не видел, есть "повисшие" документы еще с января), как со стороны клиента запросить статус ТТН, отправленных актов?
c. Появилась сложноуловимая ситуация, когда документ в УТМ пропадает. Просмотр логов УТМ не выявил проблем на первый взгляд. По логам моей системы сбора данных с УТМ получилось так, что после получения страницы /opt/out я получил список ссылок на новые документы (waybill), через 200-300мс при попытке скачать документ вернулся ответ 404 от УТМ. Сам я вызываю удаление на УТМ только когда транзация записи в наш sql отработает, а тут документ стал 404 еще задолго до вызова удаления. Если получится наткнуться еще раз на эту ситуацию - вложу логи. Пишу чтобы не забыть, и вдруг кто еще сталкивался.
d. Может ли УТМ сама удалить документ из-за отзыва в ЕГАИС (например отзыв ТТН поставщиком, вопрос возник из предыдущего пункта), в одностороннем порядке, минуя команду удаления пользователя?
f. Возможно ли доработать систему для запроса всех отправленных на определенный FSRARID номеров ТТН с возможностью их переполучения (пускай даже за определенный период)? В принципе, вопрос относится ко всем типам документов.

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

PS Почему бы не создать отдельный подфорум, куда вынести вопросы такого рода (обсуждения функционала, реализации, структур данных и схем обмена, и тп)?

[antonn]

Требуются ответы.

[Operator 4]

УТМ имеет документацию. Её можно загрузить в ЛК на egais.ru. Обратная связь: телефон, ЛК, форум.

a. Других обязательных полей не предусмотрено (КПП тоже обязательно);
b. Нет, недопустима только в том случае, если на сервере уже есть ТТН с тем же номером и от того же поставщика;
c. Технически допустимо, но см. пункт b.

2.
a. Никакие. Вы узнаёте по факту, когда придёт тикет в ответ на отправленный Вами Акт на данную ТТН;
b. Только при отсутствии любых актов, или можно отменить соответствующим тикетом на акт расхождения;
c. Из комментария;
d. WayBillTicket формируется только на акт разногласий, а Ticket формируется системой.

3.
a. Используйте проверку на https://check1.fsrar.ru/ и переотправку через ЛК на egais.ru;
b. https://check1.fsrar.ru/;
c. Нужны логи;
d. Нет, не может;
f. На данный момент запрос на переотправку ТТН доступе в ЛК на egais.ru.

[antonn]

Спасибо за ответы.

УТМ имеет документацию. Её можно загрузить в ЛК на egais.ru.

Если вы про документ "Технические требования к УТМ версии 1.7" (и ниже, что относится ко времени написания поста) - это не документация, это очень скромное описание. Где в том документе описание поля TransportId необходимое для связки квитанции отказа акта с запросом отправки акта? Где описание запроса информации о товаре 1.6.1 по КОД? Чем отличается Ticket от WayBillTicket даже тут мне не сказали. Документация должна содержать подробное описание всех полей, и это не схема xml.

b. Нет, недопустима только в том случае, если на сервере уже есть ТТН с тем же номером и от того же поставщика;

как понимать "на сервере уже есть", она всегда есть как только поставщик отправляет ТТН, или ее может не стать при отзыве ТТН (поставщиком)? Т.е. она один раз и навсегда создается или на уровне сервера может быть удалена и создана заново, но на уровне получателя это будет выглядеть как повторная прогрузка ТТН?

a. Никакие. Вы узнаёте по факту, когда придёт тикет в ответ на отправленный Вами Акт на данную ТТН;
b. Только при отсутствии любых актов, или можно отменить соответствующим тикетом на акт расхождения;

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

c. Из комментария;

Можете ли вы сейчас здесь гарантировать что формат текста комментария никогда не поменяется? Могу ли я ссылаться на ваше сообщение для подтверждения этого факта? Мне необходимо это для автоматизированной работы с документами.

Код: Выбрать все

d. WayBillTicket формируется только на акт разногласий, а Ticket формируется системой.

со стороны магазина что должно быть получено от поставщика при отправке акта? У меня всегда при безошибочной отправке приходят два документа по ссылке Ticket, и иногда приходят квитанции по ссылке WayBillTicket. Поэтому я и хочу разъяснений, зачем он нужен если мне и так два тикета падают (две квитанции по ссылке opt/out/Ticket).

a. Используйте проверку на https://check1.fsrar.ru/ и переотправку через ЛК на egais.ru;
b. https://check1.fsrar.ru/;

Где взять документацию на автоматизированную (согласно моему вопросу) программную работу с этим ресурсом?

f. Возможно ли доработать систему для запроса всех отправленных на определенный FSRARID номеров ТТН с возможностью их переполучения (пускай даже за определенный период)? В принципе, вопрос относится ко всем типам документов.

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

[Operator 4]

как понимать "на сервере уже есть", она всегда есть как только поставщик отправляет ТТН, или ее может не стать при отзыве ТТН (поставщиком)? Т.е. она один раз и навсегда создается или на уровне сервера может быть удалена и создана заново, но на уровне получателя это будет выглядеть как повторная прогрузка ТТН?

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

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

Нет, отменяет он её актом отказа, затем формирует новую.
В будущем планируется информировать соответствующим тикетом.

Можете ли вы сейчас здесь гарантировать что формат текста комментария никогда не поменяется? Могу ли я ссылаться на ваше сообщение для подтверждения этого факта? Мне необходимо это для автоматизированной работы с документами.

Нет, не можем. Данные решения лежат на стороне РАР, а их действия мы предугадать не можем.

со стороны магазина что должно быть получено от поставщика при отправке акта? У меня всегда при безошибочной отправке приходят два документа по ссылке Ticket, и иногда приходят квитанции по ссылке WayBillTicket. Поэтому я и хочу разъяснений, зачем он нужен если мне и так два тикета падают (две квитанции по ссылке opt/out/Ticket).

WayBillTicket отправляется ТОЛЬКО на акт расхождений.

Где взять документацию на автоматизированную (согласно моему вопросу) программную работу с этим ресурсом?

Документация доступна на сайте.

f. Возможно ли доработать систему для запроса всех отправленных на определенный FSRARID номеров ТТН с возможностью их переполучения (пускай даже за определенный период)? В принципе, вопрос относится ко всем типам документов.
тот же вопрос - нужны описания к запросам к ресурсам для автоматизированной работы. Ручная работа не интересует совсем, в силу больших потоков документов.

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

[antonn]

Нет, не можем. Данные решения лежат на стороне РАР, а их действия мы предугадать не можем.

Это крайне важный момент, можно ли добавить в список доработок вставку необходимых данных в существующие теги? Например писать номер ТТН в соответствующем теге RegId (заодно и в тикете акта отказа, чтобы избавиться от костыля с протягиванием TransportId и связки по нему), он же все равно заполняется при подтверждении акта. Мы не можем автоматизировать большие потоки документов не имея утвержденной структуры данных.

WayBillTicket отправляется ТОЛЬКО на акт расхождений.

Еще раз уточню: на акт расхождения высылается Ticket+WayBillTicket, а на все остальное Ticket+Ticket? Может ли быть так, что на акт расхождения приходит три квитанции (2 Ticket + WaybillTicket). Вопрос собственно потому и возник, зачем нужна эта квитанция, если я получаю два обычных тикета. WayBillTicket не сути лишний? Или поставщик опционально его может отправлять? Потому еще вопрос возник, что тикетов (включая пары) 30к, а WayBillticket - не более 2к. Актов расхождения - тьма, как-то не сходится обязательность Waybillticket на акт расхождения...

[Operator 4]

Нет, не можем. Данные решения лежат на стороне РАР, а их действия мы предугадать не можем.
Это крайне важный момент, можно ли добавить в список доработок вставку необходимых данных в существующие теги? Например писать номер ТТН в соответствующем теге RegId (заодно и в тикете акта отказа, чтобы избавиться от костыля с протягиванием TransportId и связки по нему), он же все равно заполняется при подтверждении акта. Мы не можем автоматизировать большие потоки документов не имея утвержденной структуры данных.

Обращайтесь официально в РАР для внесения предложений и пожеланий.

Еще раз уточню: на акт расхождения высылается Ticket+WayBillTicket, а на все остальное Ticket+Ticket? Может ли быть так, что на акт расхождения приходит три квитанции (2 Ticket + WaybillTicket). Вопрос собственно потому и возник, зачем нужна эта квитанция, если я получаю два обычных тикета. WayBillTicket не сути лишний? Или поставщик опционально его может отправлять? Потому еще вопрос возник, что тикетов (включая пары) 30к, а WayBillticket - не более 2к. Актов расхождения - тьма, как-то не сходится обязательность Waybillticket на акт расхождения...

1. При подтверждении акта расхождений грузополучателю приходит следующее:
Тикет "Документ успешно принят"
Тикет "Накладная проведена"
Сам WayBillTicket.

[antonn]

Обращайтесь официально в РАР для внесения предложений и пожеланий.

Вы имеете в виду http://forum.fsrar.ru/ucp.php?mode=register ? Мне ничего в соответствующем подфоруме не отображается, поэтому пишу тут:

1. При подтверждении акта расхождений грузополучателю приходит следующее:
Тикет "Документ успешно принят"
Тикет "Накладная проведена"
Сам WayBillTicket.

Вот теперь ясно, стоит указать это в документации. Спасибо.