Многие специалисты сталкиваются с классической проблемой при переходе на 64-битную платформу 1С: старое торговое оборудование отказывается работать. Разберем типичную ситуацию: имеется 64-битный сервер и клиент 1С, а драйвер эквайрингового терминала Ingenico (внешняя компонента ARCUS2) поставляется только в 32-битном (x86) варианте. Как заставить эту связку корректно функционировать, особенно в современных типовых конфигурациях вроде 1С:Розница 2.2?
Проанализируем возможные варианты решения этой задачи — от самых простых обходных путей до сложных архитектурных решений.
Самым быстрым, стабильным и часто применяемым на практике решением является параллельное использование 32-битного клиента. Платформа 1С спроектирована так, что 32-битный (x86) тонкий или толстый клиент может без проблем подключаться к 64-битному (x86_64) серверу 1С:Предприятия.
Рассмотрим по шагам, как это организовать:
/AppAutoCheckVersion или указывая прямой путь к 1cv8.exe в папке x86).Таким образом, кассиры работают в 32-битном окружении, где драйвер ARCUS2 функционирует "из коробки", а остальные пользователи базы (менеджеры, бухгалтеры) продолжают использовать 64-битный клиент.
Стандартный системный метод обхода разрядности в Windows — вызов 32-битных COM-объектов через суррогатный процесс. Суть заключается в регистрации библиотеки ArcCom.dll как серверного приложения в консоли Служб компонентов (comexp.msc).
Выясним причину, почему этот метод может не сработать в современных конфигурациях (например, "Розница 2.2"):
Если нет возможности ставить 32-битного клиента, можно "замутить прокладку". В сфере автоматизации существуют готовые утилиты (например, ComProxy). Как это работает:
Создается отдельная локальная служба Windows, которая работает в 32-битной среде. Эта служба загружает в себя 32-битную библиотеку ARCUS2, устанавливает связь с эквайринговым терминалом, а наружу (для 64-битной 1С) открывает универсальный сетевой интерфейс — например, HTTP REST API или TCP-сокеты.
В этом случае код на стороне 1С обращается не напрямую к DLL, а отправляет POST-запросы на локальный порт localhost. Прокладка транслирует запросы драйверу и возвращает ответы обратно в 1С.
Для разработчиков есть путь создания универсальной компоненты-обертки по технологии Native API x64. Алгоритм выглядит следующим образом:
Важный нюанс: Вашей прокладке придется не только транслировать базовые вызовы (оплата, сверка итогов), но и корректно пробрасывать асинхронные события от терминала обратно в 1С через метод ExternalEvent.
Не забываем про организационные методы. Программное обеспечение ARCUS2 считается устаревающим. Многие банки-эквайеры переводят клиентов на современные решения (например, INPAS DualConnector, ПО от Сбербанка или UCS).
Вендоры этих решений предоставляют современные драйверы (Native API), изначально скомпилированные и сертифицированные фирмой "1С" как в x86, так и в x86_64 вариантах. Посмотрим правде в глаза: зачастую самым быстрым и правильным решением будет звонок в техническую поддержку банка с просьбой обновить прошивку терминала и предоставить актуальный 64-битный драйвер.
Итог: Если вам нужно решить проблему "здесь и сейчас", смело устанавливайте 32-битную платформу на рабочее место кассира. Если же вы хотите системного решения без "костылей", обратитесь в банк для замены ПО терминала на современное, поддерживающее 64-битную архитектуру 1С.