Как заставить работать 32-битный драйвер ARCUS2 (Ingenico) на 64-битной платформе 1С?

Системный администратор 1С v8.3 (Управляемые формы) 1С:Розница Торговля и дистрибуция
← На главную

Многие специалисты сталкиваются с классической проблемой при переходе на 64-битную платформу 1С: старое торговое оборудование отказывается работать. Разберем типичную ситуацию: имеется 64-битный сервер и клиент 1С, а драйвер эквайрингового терминала Ingenico (внешняя компонента ARCUS2) поставляется только в 32-битном (x86) варианте. Как заставить эту связку корректно функционировать, особенно в современных типовых конфигурациях вроде 1С:Розница 2.2?

Проанализируем возможные варианты решения этой задачи — от самых простых обходных путей до сложных архитектурных решений.

Вариант 1. Использование 32-битного клиента 1С (Самый надежный способ)

Самым быстрым, стабильным и часто применяемым на практике решением является параллельное использование 32-битного клиента. Платформа 1С спроектирована так, что 32-битный (x86) тонкий или толстый клиент может без проблем подключаться к 64-битному (x86_64) серверу 1С:Предприятия.

Рассмотрим по шагам, как это организовать:

  1. На рабочем месте кассира (где физически подключен терминал) установите 32-битную версию платформы 1С.
  2. Убедитесь, что драйверы для остального оборудования на этой кассе (ККТ, сканер штрихкодов) также установлены в 32-битных версиях, чтобы избежать конфликтов.
  3. В настройках ярлыка запуска 1С для конкретной базы жестко пропишите запуск 32-битного клиента (используя параметр /AppAutoCheckVersion или указывая прямой путь к 1cv8.exe в папке x86).

Таким образом, кассиры работают в 32-битном окружении, где драйвер ARCUS2 функционирует "из коробки", а остальные пользователи базы (менеджеры, бухгалтеры) продолжают использовать 64-битный клиент.

Вариант 2. Службы компонентов COM+ (dllhost.exe)

Стандартный системный метод обхода разрядности в Windows — вызов 32-битных COM-объектов через суррогатный процесс. Суть заключается в регистрации библиотеки ArcCom.dll как серверного приложения в консоли Служб компонентов (comexp.msc).

Выясним причину, почему этот метод может не сработать в современных конфигурациях (например, "Розница 2.2"):

  1. Ограничения БПО: "Библиотека подключаемого оборудования" в новых версиях жестко регламентирует стандарты драйверов и требует использования технологии Native API, а не классического COM.
  2. Проблема обратных вызовов: Драйвер ARCUS2 использует маршалинг Callback-функций для возврата статусов (например, "ожидание пин-кода", "карта прочитана"). При использовании COM-суррогата эти асинхронные ответы часто теряются или вызывают зависание 1С.

Вариант 3. Использование прокси-сервера (TCP/HTTP)

Если нет возможности ставить 32-битного клиента, можно "замутить прокладку". В сфере автоматизации существуют готовые утилиты (например, ComProxy). Как это работает:

Создается отдельная локальная служба Windows, которая работает в 32-битной среде. Эта служба загружает в себя 32-битную библиотеку ARCUS2, устанавливает связь с эквайринговым терминалом, а наружу (для 64-битной 1С) открывает универсальный сетевой интерфейс — например, HTTP REST API или TCP-сокеты.

В этом случае код на стороне 1С обращается не напрямую к DLL, а отправляет POST-запросы на локальный порт localhost. Прокладка транслирует запросы драйверу и возвращает ответы обратно в 1С.

Вариант 4. Написание собственной ВК-обертки (Native API)

Для разработчиков есть путь создания универсальной компоненты-обертки по технологии Native API x64. Алгоритм выглядит следующим образом:

  1. Пишется 64-битная Native API компонента, которую 1С воспринимает как "родной" драйвер торгового оборудования.
  2. При инициализации эта компонента порождает дочерний 32-битный процесс.
  3. В 32-битный процесс подгружается оригинальная DLL драйвера.
  4. Методы из 64-битной ВК транслируются в 32-битный процесс через механизмы межпроцессного взаимодействия (IPC) и маршалинг интерфейсов.

Важный нюанс: Вашей прокладке придется не только транслировать базовые вызовы (оплата, сверка итогов), но и корректно пробрасывать асинхронные события от терминала обратно в 1С через метод ExternalEvent.

Вариант 5. Переход на современное процессинговое ПО (Альтернатива)

Не забываем про организационные методы. Программное обеспечение ARCUS2 считается устаревающим. Многие банки-эквайеры переводят клиентов на современные решения (например, INPAS DualConnector, ПО от Сбербанка или UCS).

Вендоры этих решений предоставляют современные драйверы (Native API), изначально скомпилированные и сертифицированные фирмой "1С" как в x86, так и в x86_64 вариантах. Посмотрим правде в глаза: зачастую самым быстрым и правильным решением будет звонок в техническую поддержку банка с просьбой обновить прошивку терминала и предоставить актуальный 64-битный драйвер.

Итог: Если вам нужно решить проблему "здесь и сейчас", смело устанавливайте 32-битную платформу на рабочее место кассира. Если же вы хотите системного решения без "костылей", обратитесь в банк для замены ПО терминала на современное, поддерживающее 64-битную архитектуру 1С.

← На главную