← На главную

Работа с банковскими терминалами в связке с 1С часто сопровождается сложностями, особенно при использовании удаленного доступа. Рассмотрим ситуацию, когда при проведении оплаты через терминал Ingenico с использованием драйвера Arcus2 в УТ 11, 1С не получает данные слип-чека, хотя транзакция в терминале проходит успешно.

Разбор природы ошибки

Первым делом выясним, где именно формируется слип-чек. Важно понимать, что 1С не участвует в отрисовке чека — она лишь выступает «слушателем» данных, которые передает терминал. Терминал через драйвер Arcus2 возвращает текстовую или структурированную информацию о результатах операции. Если 1С выдает ошибку о том, что «нет поля items», это прямо указывает на то, что до конфигурации не дошел пакет данных с расшифровкой чека, хотя физический файл cheq.out в папке драйвера может быть создан.

Основные причины отсутствия передачи данных

На основе анализа данной проблемы, выделим ключевые факторы, препятствующие корректной работе:

1. Нестабильность RDP-сессий: Самая частая причина. При использовании удаленного рабочего стола соединение с COM-портами периодически разрывается. 1С продолжает работать, но «туннель» к терминалу перестает корректно транслировать пакеты данных.
2. Проблемы с пробросом портов: Если вы используете стороннее ПО (например, Virtual Serial Ports Emulator), сбои в работе службы эмуляции приводят к тому, что драйвер Arcus2 теряет доступ к устройству.
3. Зависание сеанса: При разрыве доступа к порту внутри сеанса Windows, повторная попытка транзакции не восстанавливает корректный обмен данными, пока сеанс пользователя не будет перезапущен.

Пошаговое решение проблемы

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

Шаг 1: Проверка целостности соединения

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

• Проверьте, создаются ли файлы cheq.out в директории драйвера Arcus2 после проведения неудачной операции. Если файл создается, значит, терминал «общается» с компьютером, а проблема лежит на этапе «передачи» из файла в 1С.
• Выполните завершение сеанса пользователя на сервере терминалов. Часто это единственный способ сбросить «зависшие» виртуальные порты, которые были заняты некорректным соединением.

Шаг 2: Использование логов для анализа

Драйвер Arcus2 всегда ведет журналы работы. Проанализируем содержимое файла chek.out. Если вы видите статус 000 УСПЕШНО, значит, транзакция на стороне банка завершена. Если 1С все равно выдает ошибку, это означает, что логика обработки ответа драйвера в 1С ожидает специфическую структуру (поля items), которую драйвер не смог корректно распарсить или передать из-за повреждения потока данных в момент сессии.

Шаг 3: Минимизация рисков при RDP

Чтобы избежать подобных ситуаций в будущем, рассмотрим следующие рекомендации:

• Стабилизация портов: Если используете VSPE, настройте автоматический перезапуск программы или службы при обнаружении простоя или ошибок соединения.
• Очистка временных файлов: Периодически очищайте папку с логами Arcus2, чтобы накопленные старые файлы cheq.out не вводили систему в заблуждение при считывании ответа.
• Локальное тестирование: В качестве эксперимента попробуйте подключить терминал к ПК напрямую (минуя RDP и эмуляторы). Если проблема исчезла — значит, дело исключительно в сетевой задержке или нестабильности виртуального COM-порта.

Технический вывод

Если вы столкнулись с подобным поведением, не спешите переустанавливать драйвер или менять настройки 1С. Проблема носит инфраструктурный характер. В 90% случаев решение сводится к перезапуску сеанса пользователя или эмулятора портов. В случае, если проблема повторяется регулярно, рассмотрите возможность перевода терминала на работу через IP-интерфейс (если это поддерживает ваш банк), что позволит отказаться от нестабильных виртуальных COM-портов в пользу прямого сетевого подключения.