NCR (Card before cash)

sockspy

Добрый день Уважаемые!
При попытке перевести банкоматы NCR на работу по сценарию "Card Before Cash" столкнулся с проблемой отправки буфера AB, то есть в конфигурации указано, чтобы после стейта "withdrawal complete card" был переход на стейт J close и далее отсылания буфера AB, но переход не происходит.
В логах на хосте видно, что хост отсылает банкомату переход на 092 стейт и
банкомат отвечает на эту команду
"22\1c020\1c\1c9\1dCAM\1d9F3602000B9F2701409F2608204E93794AB828DC9F100706010A03602000950580000400009B027000"
но дальше ничего не происходит, хотя должен перейти на 134 и дальше отослать на хост AB.

Вот последовательность стейтов:
092 J063134063255010000255000 - J Close (withdrawal complete card)
134 J063135063255010000255000 - J Close (withdrawal complete)
135 D136227001002000000000000 - D Pre-Set Operation Code Buffer
136 I005103001000001000001000 - I Transaction Request

Подскажите пожалуйста есть какая-либо неточность в стейтах? В чем может быть проблема? Что я делаю не так?

Worm

Добрый день, у вас похоже ошибка в конфигурации:

092 J063134063255010000255000 - J Close (withdrawal complete card)
134 J063135063255010000255000 - J Close (withdrawal complete)
135 D136227001002000000000000 - D Pre-Set Operation Code Buffer
136 I005103001000001000001000 - I Transaction Request

В Вашем случае получается что у Вас банкомат переходит на named стейт 092 (withdrawal complete card) со скрином 063, а с 092 (withdrawal complete) переходит на 134 который тоже является JClose.
Мне кажется что правильней будет так:

092 J063135063255010000255000 - J Close (withdrawal complete card)
134 J063135063255010000255000 - J Close (withdrawal complete)
135 D136227001002000000000000 - D Pre-Set Operation Code Buffer
136 I005103001000001000001000 - I Transaction Request

Возможно это и есть ошибка, у нас просто все банкоматы Винкор, с НЦР не работал, но ДДЦ от НДЦ вроде не сильно отличается.

sockspy

Добрый день.
Спасибо за ответ.
Проблема решилась отправлением "D Pre-Set Operation Code Buffer" стейта со значением "AB---???", т.е. без J close, следом "I Transaction Request" (для обновления счетчиков на хосте). В таком случае транзакция завершается должным образом.
По непонятным причинам Aptra J close обрабатывать не хочет. Может кто-нибудь сталкивался с такой проблемой?
Осталась одна проблема, которую не смог решить.
При отправлении "I Transaction Request" и при запросе счетчиков с хоста, NCR почему то попадает в OUT OF SERVICE на 10-15 секунд.
Говорят это так и должно быть, мол NCR должен упасть в OOS чтоб отослать на хост счетчики.
Действительно ли это так и должно быть?
Версия Аптры 3.2, NCR 6622

Worm

Не знаю как у НЦР, но у Винкора при запросе счётчиков с хоста банкомат тоже "вывалиливается" а OOS, правда максимум секунды на 2.Это более чем логично, так как банкомату нужно "убедится" что в момент отылания счётчиков никто не снимает деньги.
Единственное что хотел спросить - как посылка "AB---???" на хост решает проблему с выдачей карточки ? В любом же случае должна быть комманда банкомату выплюнуть карту. Или у NCR переход на "A Card Read" стейт выплёвывает карту? На винкоре логичное завершение - такое:
1) JClose
2) D Clear Buffer ("AB---???")
3) I Transaction
А вот с JClose всё-таки проблема наверное та же, что после одного JClose, не может сразу идти второй JClose, это видимо "ломает" логику Аптры. Попробуйте переконфигурировать конфигурацию как я предлагал, что оба JClose уходят на "D Pre-Set Operation Code Buffer" который вписывает "AB" и переходит на "I Transaction"

sockspy

Worm

Да я просто приблизительно написал, у меня тоже наверное где-то 2-5 сек длится на NCR, но суть не в этом.
На Винкорах такое не наблюдается, может из-за того, что они на DBL протоколе работают у нас.
"AB---???" отсылается не с банкомата, а с хоста. Мы просто решили в логическом завершении не использовать J Close, т.е. так
1) D Clear Buffer ("AB---???")
2) I Transaction
Логичное завершение по NDC и по DBL должно быть так, как вы написали.
Точно не помню, но вроде с одним J Close тоже пробовал тоже не срабатывал, но еще раз попробую, протестирую.
Еще замечено проблемы с EMV стейтами. Например "; ICC Re-initialise" не срабатывает.
По документации, при переходе на именованные стейты(типа chip inquiry, chip withdrawal и т.д.) в первую очередь надо дать "; ICC Re-initialise", но почему то тут тоже не обрабатываются эти стейты банкоматом. Приходится без "; ICC Re-initialise" обходится, что в свою очередь создает проблему. Например начатая чиповая транзакция, при вторичном обращении к чиповым стейтам проходят по магнитной полосе.
Короче говоря не нравится мне этот NDC протокол

По мне так DBL лучше.

Worm

Например начатая чиповая транзакция, при вторичном обращении к чиповым стейтам проходят мо магнитной полосе.

Хммм а вот это уже грустно - это fallback, за который нас бы Виза с Мастеркардом в порошок растёрли =)
"; ICC Re-initialise" это "e EMV Chip Card State" с параметром "002 - Start/Restart EMV Application" по Диболду ?
У нас таких проблем не было. Может конфиг банкоматовского софта кривой ?

sockspy

Worm писал(а):ммм а вот это уже грустно - это fallback, за который нас бы Виза с Мастеркардом в порошок растёрли =)

В том то и дело, что это не fallback, т.к. Point Code 7-я позиция видна как 9 а не 8.

Worm писал(а):"; ICC Re-initialise" это "e EMV Chip Card State" с параметром "002 - Start/Restart EMV Application" по Диболду ?

Да точно, только это не по Diebold, а Wincor DBL

Worm писал(а):У нас таких проблем не было. Может конфиг банкоматовского софта кривой ?

Банкомат совсем новенький, софт тоже, но всякое может быть.
Вот пытаюсь выяснить причину.

sockspy

Worm писал(а):Не знаю как у НЦР, но у Винкора при запросе счётчиков с хоста банкомат тоже "вывалиливается" а OOS, правда максимум секунды на 2.Это более чем логично, так как банкомату нужно "убедится" что в момент отылания счётчиков никто не снимает деньги.

Кстати, а этот Винкор случаем не по NDC работает?
И когда он "вываливается" в OOS то картинку назначенную для OOS показывает?
У меня такое не наблюдается, ни при запросе счетчиков с хоста, ни при "I Transaction Request" в конце транзакции.

Worm

Кстати, а этот Винкор случаем не по NDC работает?
И когда он "вываливается" в OOS то картинку назначенную для OOS показывает?
У меня такое не наблюдается, ни при запросе счетчиков с хоста, ни при "I Transaction Request" в конце транзакции.

Винкор у нас тоже работает по Wincor Diebold. Картинку OOS показывает только при запросе счётчиков и STA. Никаких выпаданий в OOS после "I Transaction Request" не замечал.

sockspy

Worm
Честно говоря мне как-то по барабану что банкомат вываливается в OOS, на работу банкомата и на меня это никак не влияет.
Самое главное чтоб клиенты это не видели во время транзакции.
Их, так сказать это "пугает".

Worm

хммм, но всё-таки странно насчёт "I Transaction". А можно глянуть на кусочек ATMIF лога, без номеров карт разумеется, где банкомат выпадает в OOS во время транзакции. Хочу глянуть на это чудо, может когда - нибудь сами столкнёмся с такой проблемой =)
P.S. А вы кстати какой технический мониторинг используете ? Gasper или Proview ?

sockspy

Worm
В данный момент другими проблемами занят.
Как руки дойдут до него, выложу кусок ATMIF лога.
У нас вообще то ATM мониторинг от самого Tieto, другие не используем.
Нам его хватает)

Worm

А у нас Proview + Тието. Они друг друга очень хорошо дополняют. =)

sockspy

Worm
Кстати еще у нас замечено в атм мониторинге все время висит ошибка SFT на Encryptor.
Даже в новых банкоматох как включаешь такое бывает.
Может знаешь как лечится?
У вас вообще такое есть?

Worm

sockspy
Эммм... У нас такой проблемы нет. STA пробовал посылать ?

sockspy

Worm
Да пробовал, всеравно ошибка висит.
Причем не на всех NCR-ах такое наблюдается.
Но бывает даже на новых, как только подключается к процессингу сразу с такой ошибкой в мониторинге появляется.
Хотя говорили это при неправильном вводе ПИН-а такое может быть, типа это не критично, а информативно.
Имхо такое объяснение не подходит к новым банкоматом, на которых ни разу еще не вводили ПИН.

Worm

sockspy
У меня такое чувство,что хост некоректно обрабатывает статус EPP. Из-за этого скорее всего и появляется SFT статус. Или сразу при подключении в базу заносится такое значение. Если на эту таблицу в Оракуле есть журнал, можно глянуть откуда ноги у статуса растут, и в какой момент этот статус в базе меняется. Если я не ошибаюсь то это была таблица ATM_DEVICES.

sockspy

Worm
Да черт с этим EPP.
Меня ща мучают по другому вопросу.
Достали меня с вопросом почему в новых НСР-ах, в которых версия АПРТА выше 3.2, в конце транзакции когда отсылает "Transaction request" банкомат показывает скрин OOS.
Не знаю как это лечить, может кто знает как это настроить на банкомате?
Может есть где-то в настройках банкомата параметр timeout OOS, с помощью которого можно назначить время через сколько сек переходить в OOS при получении команды и при отсылке "Transaction request" ?
Где вообще хранятся такие тонькие настройки в новой версии?

Worm

Тут уж я, увы, не помогу, так как НСР видел только на картинках. Но как-то слабо верится что проблема заключается в Аптре, Тието не пробовали логи отсылать ?

sockspy

Worm
Были такого рода ошибки, они отказали в поддержке, ответив при этом, что надо обращаться к вендору по таким вопросам.
Я уже отправил логи вендору, жду ответа.
Но больше чем уверен, что проблема в АПТРЕ, т.к. судя по debug логам он неправильно обрабатывает J close.
Такой вопрос к тебе, gif файлы пробовал использовать в конфигурации Screen-ов?
У меня почему-то они не проигрываются.