Clarion и терминал карт СБЕРА

[Игорь Столяров]

То есть Вы не используете транзакции? А если в процессе печати слипа или фискального чека возникли проблемы?

Это две большие разницы. Слип-чек - это обычный текст. Но даже в этом случае работает повтор при аварийном завершении процесса печати (по крайне мере для АТОЛ и ШТРИХ-М). А уж для фискальных кассовых чеков есть специальные команды и алгоритмика обработки аварийного завершения печати ...

И опять таки про желаемое, действительное и их корреляцию. Не надо придавать слип-чеку статус документа. Это просто информационное сообщение из банка в текстовом виде, как и смс. И если закон регламентирует содержание кассового чека (ФЗ-54), то состав слип-чек - произвольный. Например в известном проуктовом супермаркете после (!) кассового чека печатают 2 строчки о банковской проводке с карты: дата, последние 4 номера карты, номер транзакции и сумма. Всё. Зато у некоторых "ИП Васильков" слип-чек + кассовый чек на 3 позиции длиной пол-метра ленты. Законы не читают, а потому дрожат и боятся как бы чего не дадать ...

[Игорь Столяров]

А еще алкаши бегают, как лани.

Я понимаю, что это сложный бизнес со своей спецификой … Особенно когда надежда зависит от попискивания какого-то
там прибора размером с мыльницу … у любого нервы сдадут.

[finsoftrz]

Ну, судя по тому, что я на данный момент знаю, наличие слипов и срок их хранения прописываются в договорах эквайринга, которые магазины заключают с банками. Если не печатать слипы, то в случае всяких разборок (с банком или покупателями) сложно что-то будет предъявить.
Я сейчас не очень в курсе всех этих нюансов. Но, как понимаю, это хорошая практика - сохранять слипы в базе данных. И по платежам в банк, и по Егаис. Чтобы в случае чего их можно было повторно распечатать. Вот, недавно читал про подобную ситуацию. Речь правда, не про банковский слип, а про Егаис. Продал магазин бутылку некоей особе. Она потом прибегает и говорит, вы не дали мне слип из Егаис, наверно, продали мне контрофакт. И большим подспорьем оказалось то, что кассовая программа хранила слипы. Продавец быстро нашел нужный чек и распечатал копию слипа. Конфликт был исчерпан. Не надо забывать, что неадекватными могут быть не только продавцы, но и покупатели. Розничная торговля имеет свои прелести...

[finsoftrz]

Надыбал рабочий сберовский терминал, развлекаюсь... Интересная особенность. Я создаю ole в базовом окне приложения и там же инициализирую класс. А затем по ссылке на этот класс работаю в других местах. Для сберовского драйвера важно, чтобы было активно окно, в котором создан Ole контрол. Поэтому пришлось при инициализации класса передавать ссылку на окно, а затем в методах делать скобки из settarget(SELF.Wind) и settarget, в них уже вызывать функции драйвера. Так все работает.

[Игорь Столяров]

Да. Есть ещё такое наблюдение: в контексте работы с Clarion, cберовский объект эквайринга, "любит" чистый поток (Thread).
Т.е. если многократно инициализировать OLE эквайринга в одном и том же MDI окне - рано или поздно его переклинит.
Поэтому у нас эквайринг всегда вызывается в новом потоке, который потом убивается вместе OLE объектом сбера - так без проблем.

[finsoftrz]

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

Попробовал работу с транзакциями. Переходить в режим неподтвержденной транзакции надо сразу после успешного проведения платежа. Если потом откатывать, то приходит вторая sms с сообщением на отмену. Еще в каталоге драйвера в файле pinpad.ini можно установить режим работы без вывода окон. Это как раз мой случай, так как в магазинах у клиента оплата производится обычно отдельно для 2 отделов. То есть кассир нажал кнопку "Оплата по безналу", дальше все автоматом должно делаться (кроме, конечно, случая аварийного завершения). Печатаем предчек (сводный чек по всем отделам), шлем продажу в Егаис (если в чеке есть алкоголь), получаем ответ от Егаис, печатаем его слип. Запрашиваем пинкод по первому отделу (если их несколько). Покупатель вводит, печатаем слип банка и фискальный чек по отделу. Затем запрашиваем пинкод по второму отделу и т.д. Процесс довольно непростой получается, так как возможны сбои на разных его этапах. Если штатно откатить не удается (например, сбой при отправке отмены чека в Егаис), то чек остается в режиме аварийного состояния, с ним разруливать надо отдельно. Соответственно, в чеке фиксируется состояние прохождения каждого этапа...

[Игорь Столяров]

А зачем его многократно инициализировать?

Если это место кассира с одним SDI-окном, в котором он(-а) живёт - то действительно не надо.
Хотя я бы проверил, что будет с памятью и вызовом через пару сотен обращений к эквайрингу.
Просто бывают программы в которых оформляется параллельно сразу несколько чеков, потом
все это (как-то) печатается и оплачивается - но это уже совсем другая история ...

Из описания работы с транзакциями не понял главного: зачем весь этот процесс печатать по ходу действия ?
Даже если реализация в разные отделы оформляется отдельными проводками, почему всё это не запросить
сначала, в т.ч. и операции эквайринга с демонстрацией сумм к оплате на пинпаде, и только в случае успеха -
уже весь набор кассовых-слип чеков отправлять на печать, а при проблеме - просто прервать операцию с откатом ?

[finsoftrz]

Этот процесс надо осмыслить. Если оплата по первому отделу прошла нормально, то продажа части товаров считается состоявшейся. Если, к примеру, при продаже по второму отделу не хватило денег на карте, то отката не должно быть. У кассира висит окно оплаты, в котором в списке к оплате строка по оставшемуся отделу. Кассир спрашивает у покупателя, что делать. Либо он оплатит наличными, тогда кассир жмет клавишу "Оплата наличными" и программа переключается в соответствующий режим (запрашивает сумму, считает сдачу) по оставшемуся отделу. Либо он говорит, что денег нет, кассир поворачивает ключ на клавиатуре и в появившемся меню выбирает "Аннулирование чека", что приводит отмену продажи по второму отделу. Если покупатель говорит, что и по первому отделу ему ничего не надо, то кассир снова поворачивает ключик уже в основном окне, выбирает "Аннулирование чека" и находит нужный чек (как правило, по номеру и дате). В этом режиме нам надо послать чек на возврат на фискальный регистратор и возврат оплаты по платежному терминалу. Насколько знаю, если в чеке прошел алкоголь, то аннулировать его запрещается. В этом случае надо делать возврат выборочных позиций вместо аннулирования всего чека.

В общем, там нюансов много. Я все до конца не знаю, пока изучаю, как у других работает. Программа вроде как небольшая, но очень специфичная...

[finsoftrz]

Да, еще, откатывать по эквайрингу можно только текущий платеж. Если у нас при продаже 2 платежа, то работает отдельная транзакция для каждого. Хотя сберовская инструкция очень скудная, там еще всякие операции перечисляются без пояснений...

Еще на такой момент наступил. Если послать платеж по несуществующему отделу, то на пинпаде все равно выдается приглашение вставить карту, а потом пишет что-то типа замените карту и возвращает какие-то невнятные коды ошибок...

[Игорь Столяров]

Задача получается не из простых.
Так ещё и интерфейс должен быть под работу одной рукой.
Т.к. вторая рука выполняет LOGOUT() бутыля до COMMIT платежа …

[finsoftrz]

Да, интерфейс весьма специфический. Без мыши, с нестандартной клавиатурой, без выхода за рамки приложения. Главное не дать юзеру максимум возможностей, а максимально его ограничить и контролировать.

[finsoftrz]

Вот еще парочка скриншотов.

[Admin]

В Ашане прога на Кларион? Да ну!

[finsoftrz]

Это шутка такая...

[Игорь Столяров]

В Ашане прога на Кларион?

А почему бы и нет, особенное если знатная программа ?
До самого успокоения души, дивизионы "Техносилы" на юге РФ работали в проге на Clarion ...