Ошибка отказа ТТН, без какой-либо причины.

[OlololeC]

Умеем 3и УТМ, сегодня с утра на 2х из них перестали уходить ТТН.
Отправляется все нормально, из "Исходящих" в УТМ накладная пропадает. В ответ приходит "Квитанция фиксации" в статусе "Rejected" без указания какой либо причины. В комментарии просто пишет (" Владелец ["**********"], накладная "*********"."). Хочу обратить внимание на странный пробел в начале.
Вот весь текст одной из фиксации:

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

<?xml version="1.0" encoding="UTF-8"?>
<ns:Documents xmlns:ns="http://fsrar.ru/WEGAIS/WB_DOC_SINGLE_01" xmlns:oref="http://fsrar.ru/WEGAIS/ClientRef" xmlns:tc="http://fsrar.ru/WEGAIS/Ticket" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" Version="1.0">
   <ns:Owner>
      <ns:FSRAR_ID>3463047</ns:FSRAR_ID>
   </ns:Owner>
   <ns:Document>
      <ns:Ticket>
         <tc:TicketDate>2017-07-31T04:41:21.3005875</tc:TicketDate>
         <tc:Identity/>
         <tc:DocId>F25CDDF8-625F-488C-89D2-47C096BF8AA1</tc:DocId>
         <tc:TransportId>81411d0f-ffb8-4b44-a37f-3b4545ed37cc</tc:TransportId>
         <tc:RegID/>
         <tc:DocHash/>
         <tc:DocType>WayBill_v2</tc:DocType>
         <tc:Result>
            <tc:Conclusion>Rejected</tc:Conclusion>
            <tc:ConclusionDate>2017-07-31T04:41:21.3005875</tc:ConclusionDate>
            <tc:Comments>  Владелец ["030000002640"], накладная "28625166-ffa1-48c6-a586-a0983003c488".
</tc:Comments>
         </tc:Result>
      </ns:Ticket>
   </ns:Document>
</ns:Documents>

Пробовал уже все возможные манипуляции, кроме переустановки УТМ. Я начал было грешить на нашу учетную программу, но на прошлой неделе никаких обновлений не происходило и все фактуры выгружались штатно.

P.S. Как уже написал выше, на двух УТМ вот такая ошибка, а один работает штатно, и все отправляется. Работа со всеми УТМ осуществляется из одной учетной системы. И причем на косячных УТМ нормально обрабатываются запросы Организаций, Алкогольной продукции, а так же прогружаются Акты подтверждения на предыдущие фактуры.

P.S.S. Полностью переустановили УТМ, проблема не исчезла, думаю теперь точно выполнил все возможные манипуляции.

ПОМОГИТЕ!!! Уже не знаю куда копать.

[OlololeC]

Удалось откопать из-за чего возникает ошибка.
Если ТТН уже отправлялась в УТМ и была возвращена с ошибкой "необеспеченный расход" , мы в свою очередь скорректировали ТТН (поставили другие справки Б - на который точно есть остаток) и отправили повторно, то тогда начинает возникать данная ошибка. Как бы мы не правили документ и сколько бы раз не отправляли он выдает ошибку описанную в первом сообщении.
Это очень странно, так как раньше система спокойно позволяла заново отправлять документы с необеспеченным расходом (естественно исправлять и отправлять).
Как быть? Пробовал отвязать ТТН ЕГАИС от нашего расходного документа, и создать новый на основании, все равно одна и таже ошибка, насколько я понял он проверяет по номеру нашего дока. Но номер уже изменить нельзя, так как фактура распечатана и находится у Экспедитора.

[Yoreg07]

Доброе утро. У меня точно такая же проблема. Правда, мы не получали необеспеченный расход. Дело было так: выслали ТТН, потом увидели свою ошибку и сами отозвали и повторно теперь не может выслать. Операторы, поясните, что это такое?

[Yoreg07]

Доброе утро. У меня точно такая же проблема. Правда, мы не получали необеспеченный расход. Дело было так: выслали ТТН, потом увидели свою ошибку и сами отозвали и повторно теперь не может выслать. Операторы, поясните, что это такое?

На форуме fsrar говорят, что Identity у ТТН должен быть уникальным. Операторы, пусть программисты ваши сделают адекватный текст в тикете при отказе в фиксации ТТН.

[OlololeC]

Доброе утро. У меня точно такая же проблема. Правда, мы не получали необеспеченный расход. Дело было так: выслали ТТН, потом увидели свою ошибку и сами отозвали и повторно теперь не может выслать. Операторы, поясните, что это такое?

На форуме fsrar говорят, что Identity у ТТН должен быть уникальным. Операторы, пусть программисты ваши сделают адекватный текст в тикете при отказе в фиксации ТТН.

Да действительно проблема была в Identity, хотя раньше он спокойно отправлял с одним и тем же идентификатором по 100 раз, если были какие-то ошибки. Странно что в документации написано, что поле заполняется по желанию и вообще может быть пустым.
Спасибо большое!!!

P.S. В любом случае это какой-то бред, менять пользовательский идентификатор при каждом переотправлении ТТН если возникли ошибки.

[Yoreg07]

Операторы, почему уже в который раз вводятся какие-нибудь ограничения или проверки БЕЗ ПРЕДУПРЕЖДЕНИЯ ??? Ведь этот Identity вообще по схемам не обязательный, а если его заполняем, то ведь это идентификатор накладной, а не попытки её отправки (можно сказать транспортного пакета), и его заполнение на усмотрение отправителя. Что-за беспредел ??? У людей ведь учётные системы написаны исходя из XSD схем, и что им сейчас делать? обращаться в поддержку для доработки? или накладные плодить?

[Natasha_kvs]

Полностью поддерживаем!!!!!
С субботы не можем нормально работать!!!

[Operator 4]

1. Вы обращаетесь на форум ЦентрИнформ с просьбой доработки УТМ, что не верно.
2. На стороне сервера идет проверка уникальности СИО+дата+номер , если они не уникальны, то сервер проверит дополнительно Identity, и если при этом он будет отсутствовать или окажется не уникальным, то ТТН будет отвергнута сервером. При этом, Identity не будет обязательным.

[CrAzY_TiTaR]

Я просто настоятельно рекомендую всем заргистрироваться на официальном форуме фсрар и следить там, так как подобные нововведения обсуждаются только там. Мнения и пожелания участников ЭТОГО форума Гущанский не учитывает.

[Joyshua]

1. Вы обращаетесь на форум ЦентрИнформ с просьбой доработки УТМ, что не верно.
2. На стороне сервера идет проверка уникальности СИО+дата+номер , если они не уникальны, то сервер проверит дополнительно Identity, и если при этом он будет отсутствовать или окажется не уникальным, то ТТН будет отвергнута сервером. При этом, Identity не будет обязательным.

Да, но почему то до недавнего времени он НИКОГДА не проверял Identity, даже если СИО+дата+номер были одними не тем же