ccTalk: чому купюроприймач досі говорить цією мовою

Як це працює

ccTalk — послідовний протокол на одній лінії даних, 9600 біт/с. Кожен пристрій має свій номер, і господар шини звертається до нього за цим номером. Пакет простий: кому, скільки байтів, яка команда, дані, контрольна сума. Ніякої магії й майже ніякого накладного навантаження.

Головна відмінність від MDB у ролях. У торговому автоматі головний — сам автомат, і периферія живе в його світі. У кіоску чи на мийці головний — ваш контролер або промисловий комп’ютер. Тобто ccTalk — це протокол, яким ВИ опитуєте гроші, а не той, у який ви вбудовуєтесь.

Практично це означає більше свободи й більше відповідальності. Немає чужого VMC, який щось вирішить за вас; але й пояснювати пристрою, коли вмикати прийом, а коли ні, доведеться вам.

Навіщо купюроприймачу шифрування

Лінія ccTalk фізично доступна: це пара проводів усередині корпусу. Якщо на неї подати правильно складений пакет, система повірить, що купюру прийнято. Саме тому у протоколі є режим із шифруванням — щоб підроблене повідомлення не проходило.

Звідси головне практичне правило: у пристрої, який приймає готівку в необслуговуваній точці, шифрування має бути ввімкнене, а ключ — не заводський. Купюроприймач із відкритою лінією в терміналі на вулиці — це не технічна дрібниця, а спосіб втрачати гроші тихо й регулярно.

Зворотний бік: ключ треба десь зберігати й якось оновлювати в полі. Це питання варто вирішити на етапі проєктування, а не тоді, коли пристрій уже замурований у корпус на іншому кінці області.

Чому «приймає, але не бачить»

Найчастіша причина — пристрій у режимі, де він приймає купюри, але тримає їх «на утриманні» й чекає підтвердження від хоста. Не отримавши підтвердження, він за таймаутом повертає купюру або зараховує її, а система про це вже не знає. Виглядає це як зникла купюра, хоча насправді розсинхронізувались дві сторони.

Друга причина — лічильник подій. Правильна робота з ccTalk означає не «слухати, чи не прийшло чогось», а регулярно питати лічильник і розбирати різницю. Якщо система перезапустилась і перечитала лічильник з нуля, події між перезапусками зникають з обліку.

Третя — живлення й довжина лінії. Купюроприймач у момент протягування купюри споживає помітно більше, ніж у спокої. Просідання живлення в цей момент дає збій рівно тоді, коли в машині гроші, — і майже ніколи на столі під час тестів.

Що записувати, щоб потім було що звіряти

Мінімум, який рятує: час, номер пристрою, номінал, значення лічильника до й після, результат. Саме пара «до і після» дозволяє потім довести, що подію не загубили, навіть якщо звʼязок із сервером у той момент був відсутній.

Окремо — журнал станів пристрою: заклинило, касета повна, касету знято, спроба шахрайства. Ці події не про гроші, але саме вони пояснюють дірку в виручці за конкретну ніч.

І дата з часом за Києвом, збережена в UTC. Готівкова звірка завжди йде по змінах, а зміна — це людський час. Пристрій, який пише час у своєму часовому поясі, створює розбіжність у три години, яку потім шукають тижнями.

Коли ccTalk не потрібен взагалі

Якщо точка може працювати без готівки — вона має працювати без готівки. Купюроприймач — це інкасація, касета, знос, підробки й окрема відповідальність. Там, де клієнт платить карткою або з телефона, все це просто зникає.

Реалістично готівка потрібна там, де її частка помітна: придорожні мийки, ринки, точки з клієнтами без карток. Рішення приймають не за принципом, а за часткою в звіті — і саме тому спершу варто рік бачити цю частку в цифрах.

Якщо готівка лишається, тримайте її окремим контуром: інший пристрій, інший журнал, інша звірка. Змішаний облік готівки й безготівки в одній таблиці — головна причина, чому недостачу неможливо розслідувати.

Часті питання