Периодические проблемы при отправке чека.

[markers]

Добрый день!
Обслуживаем большое количество магазинов, торгующие марочной продукцией и периодически возникает проблема, я для начала опишу схему:
1) Магазин отправляет чек в УТМ
2) В данный момент, криптоключ работает не стабильно ("отвалился" но не полностью)
3) ЕГАИС пытается подписать чек и уходит в себя
4) Учетная программа (1С:Розница), ждет 60 секунд ответа от УТМ но так и не дождавшись ответа от него, сообщает пользователю "ну не смогла я"
5) Магазин обращается в техническую поддержку и проблему с ключем решают банальным "вытащить и вставить"
6) Пробуют пробить повторно чек, однако УТМ радостно сообщает "Подписание предыдущего чека не завершено" (наложенная блокировка на отправку новых чеков, согласно схемы 2, приложения А, документации к УТМ 205).
7) Перезапускают компьютер/УТМ, информация из памяти УТМ о не завершенном чеке пропадает
8) Пробуют пробить чек повторно, однако сюрприз, "проверка не пройдена", марочки то у вас задублированные
9) Проходит n-ое время и чек с этими же марками уже пробивается.

Теперь собственно вопросы:
1) 1С ждет ответа от УТМ 60 секунд, в документации к УТМ написано что он периодически проверяет, есть ли связь с кассовой программой и каким он это образом проверяет, если УТМ "завис" на моменте подписания чека?
2) Можно конечно увеличить время ожидания ответа от УТМ до 120, 240, 320 .. секунд, но по моим наблюдениям, если УТМ "подвис" при работе с криптоключем (получает/отправляет документы) то его можно не ждать, может необходимо в самом УТМ сделать таймер ожидания подписи документа ключем?
3) В документации говориться о параметре "delete.invalid.cheque.enable=true", может ли он как-то помочь в данной ситуации?
4) Ну и классический, кто виноват и что делать.

Заранее спасибо!

[markers]

К сожалению, проблема повторяется, а решения так и нет.

[Operator 4]

Для доработки УС 1С, обратитесь к его разработчику.

[markers]

Для доработки УС 1С, обратитесь к его разработчику.

Речь идет не о доработке УС, её я и сам доработаю как нужно, речь идет о том, что УТМ в момент подписания чека при нестабильно работающем ключе уходит в себя и возникает описанная выше проблема. В коде конфигурации 1С:Розница, можно увеличить время ожидания ответа УТМ хоть до бесконечности, но по моей практике - это ничего не изменит. Моё мнение, необходимо внутреннее ограничение на время подписания документа в УТМ, на которое бы ориентировалась и УС 1С:Розница и другие. Вины УС тут нет, оно тоже не может ждать вечно ответа от УТМ находясь в "подвисшем" состоянии. Повторюсь, первопричина проблемы в том, что УТМ не в состоянии за разумные сроки подписать документ с нестабильно работающим ключем.
PS: В более старых версиях 1С:Розница, небыло ограничения на ожидание ответа от УТМ (либо оно было значительно большее), но это не приводило к решению обозначенной проблемы, а приводило к тому что в след УТМ, висла и УС ожидая ответа от УТМ.
PS2: Мы самостоятельно дорабатываем 1С:Розница и смогли бы самостоятельно исправить проблему, если бы она была в плоскости УС (повторю, всё на что мы можем влиять из УС на эту проблему - это время ожидания ответа от УТМ, которое повторюсь - не поможет).

[Operator 4]

delete.invalid.cheque.enable=true (2.8)
Настройка позволяет выполнять автоматическое удаление не прошедших валидацию
чеков из папки UTM\transporter\xml сразу после возвращения ответа с ошибкой валидации
кассе.

Это касается только чеков которые не прошли онлайн-проверку, которая осуществляется в течение 3-х секунд на стороне сервера и возвращает ответ. После перезапуска ключа, когда УТМ работоспособен, она начинает отправлять документы накопленные в буфере, чеки которые там остались еще не проходили проверку. К вопросу "Может необходимо в самом УТМ сделать таймер ожидания подписи документа ключом?"- Вы обращаетесь на форум ЦентрИнформ. Рекомендуем на ПК где установлен УТМ, проверить наличие стороннего ПО, других криптоключей и прочей внешней периферии. Так же рекомендуем проверить ключ на его работоспособность(можете приложить transport_info.log)