У разі виникнення додаткових питань
чи пропозицій
розкажіть про це нам.
Ми з радістю вам допоможемо
¶ Початок роботи із застосунком
Ознайомитись з інформацією як працює застосунок та які задачі може вирішувати можна за посиланням
Для початку роботи потрібно буде виконати певні дії з налаштування які будуть залежати від того чи будете ви використовувати якийсь один пристрій, наприклад тільки ПРРО або і принтера та термінали також.
Більш детальна інформація щодо налаштування тестового та робочого режимів розміщена у окремих роздалах у пункті Можливості Device Manager
¶ Загальна інформація щодо API
-
Після встановлення і запуску разом із застосунком піднімається веб сервер на порті
3939(можна змінити через конфігураційни файл) який може приймати REST API запити. Вебсервер за замовчеванням доступний як по localhost так і з іншого пристрою з мережі, проте, за потреби, можна змінити налаштування (лише у версії для Android) для доступу до застосунку лише по localhost. -
За замовчуванням для передачі даних використовується
http. За потреби можна підключити сертифікат (лише у версіях для Windows та Linux) для використанняhttps. При підключенні сертифікату також враховуйте що облікова система, що відправляє запити, має довіряти цьому ж сертифікату.
Одночасно не піднімається 2 вебсервери: один по http інший по https
Після додавання сертифікату (якщо він валідний) будуть прийматись запити лише по https ну і навпаки якщо сертифікату немає - тільки http, відповідно і у вебінтерфейс потрібно переходити вказуючи https.
-
Для налаштувань (додавання ПРРО, принтерів, терміналів, перегляд чеків, тощо) використовується вебінтерфейси які доступні за посиланням:
Підключення та налаштування ПРРО та застосунку загалом:http://{{dm_ip}}:3939/dm/vchasno-kasa/
Підключення та налаштування POS пристроїв:http://{{dm_ip}}:3939/dm/
{{dm_ip}}- IP адрес пристрою на якому встановлено додаток, тобто хост. Якщо запити відправляються на локальний додаток тоді використовуєтеlocalhost.
Доступ до вебінтерфейсу, та API методів для налаштування, в разі потреби, можна закрити авторизацією по логіну і паролю через налаштування. -
Для зручності при інтеграції на виконання певних дій (фіскалізувати чек, перевірити інформацію про статус зміни по ПРРО, надрукувати чек чи провести оплату по терміналу) запити відправляються на один API ендпоінт.
Для розуміння на який пристрій (ПРРО, принтер чи термінал) який запит буде відправлено та які дії потрібно виконати використовуєтсья:
Назва пристрою("device"). Довільна назва що вказується при створення ПРРО, принтеру, терміналу чи іншого пристрою і є унікальною в межах всіх доданих притсроїв у застосунку.Тип завдання("type"). Визначає яке завдання має бути виконано. Які є види завдань:fiscal(виконання певної дії по ПРРО),pay(завдання оплати чи інших операцій по терміналу),doc(завдання для друку чи операцій з принтерами).Номер завдання("task"). Виначає номер потрібного fiscal або pay завдання для виконання. Наприклад передача типу fiscal і номеру завдання 1 сформує чек.
ДМ аналізує ці вхідні дані відповідно до них виконуються потрібні дії і повертаєтсья відповідь.
¶ Можливості Device Manager
Device Manager (далі ДМ) як інтеграційний застосунок через API відкриває можливості для виконання різних задач від налаштування до фіскалізації і прийому оплат через термінал.
Документація API та інших схем роботи поділена на кілька частин для більш предметного розбору конкретного процесу.
Для того щоб ознайомитись з потрібною частиною API натисніть на одне із посилань нижче.
- Формування чеків, звітів та робота з ПРРО Вчасно.Каса (
fiscal api).
- Прийом оплат за допомогою терміналу (
pay api).
- Друк та робота з принтерами і грошовими ящиками (
doc api).
- Прийом оплат через термінал та друк на принтері разом з фіскалізацією чеків для хмарних облікових/касових систем.
- Прийом оплат через термінал у смартфоні та підключення такого на заміну класичним терміналам до іншого пристрою.
- Режим емуляції роботи РРО.
- Налаштування та керування роботою застосунку.
¶ Changelog
Зміни в API прив'язані до версії застосунку. Усі зміни можна знайти на окремій сторінці.
¶ Рекомендації по інтеграції та роботі
В даному розділі розміщені рекомендації по інтеграції і роботі з застосунком Device Manager в контексті різних пристроїв.
¶ Таймаути на очікування відповіді по API
Рекомендований таймаут на очікування відповіді буде відрізнятись залежно від пристрою та схеми роботи:
- Робота з ПРРО (відкриття зміни, фіскалізація чеків, формування звітів) - не менше
20секунд. - Робота з принтером (Друк або відкриття грошового ящику) - не менше
6секунд. - Робота з терміналом (Оплата, повернення, скасування та інші операції) - за замовчуванням
310секунд. - Робота в пакетному режимі - залежно від того які пристрої підключено до ПРРО, якщо і принтер і термінал - тоді складаємо всі таймаути що зазначені вище.
Чому саме такі таймаути?
-
Робота з ПРРО: 99% часу фіскалізація чеку займає до 1 секунди часу, проте відкриття або закриття зміни може тривати довше, в середньому до 5 секунд, але це не основне. Бувають випадки коли є проблеми які унеможливлюють роботу в онлайн режимі, наприклад збої в роботі серверу ДПС або АЦСК ключа, або проблеми в мережі, в таких випадках застосунок, на основі внутрішніх таймаутів чи помилок, ініціює автоматичний перехід каси в офлайн. Саме на час такого переходу процес фіскалізації може затримуватись. Тому щоб не було проблем коли облікова програма не отримала відповіді на API запит - рекомендований таймаут не менше 20 секунд.
-
Робота з принтером: Таймаут для друку 5 секунд, якщо протягом 5 секунд не вдалось доставити завдання для друку на принтер - Device Manager повертає помилку.
-
Робота з терміналом: В середньому час проведення однієї оплати після прикладання картки 10 секунд, проте, час на очікування прикладання картки за замовчуванням варіюється від 40 до 60 секунд також сюди додається час авторизації оплати чи іншої операції на стороні банку який фактично не має як такого таймауту. Тому щоб уникнути проблем з отриманням відповіді від терміналу коли він може працювати повільно рекомендовано поставити саме таймаут
310секунд. За замовчуванням таймаут очікування відповіді від терміналу 300 секунд, це значення можна змінити в налаштуваннях терміналу в будь який час якщо цього часу забагато або недостатньо, тоді облікова система має мати таймаут:час таймауту в налаштуваннях терміналу + орієнтовно 10 секунд
¶ Паралельна робота
ДМ стандартно працює повністю паралельно, тобто можна відправляти кілька різних API запитів і всі вони будуть оброблені одночасно.
Проте наявні певні обмеження які залежать від бази даних та самого API запиту.
-
Якщо ДМ працює під управлінням стандартної SQLite бази даних - абсолютно всі запити які повертають якусь інформацію про ПРРО, чеки, термінал чи принтер, редагування налаштувань та фіскалізація чеку будуть виконуватись згідно внутрішньої черги.
Наприклад в ДМ працює 2 каси, з фронт системи приходить одночасно 2 запити на фіскалізацію чеку (по одному на кожну із кас), в такому випадку фіскалізація чеків буде здійснюватись по черзі по кожній касі, ці затримки можуть бути не помітні на швидких накопичувачах на пристрої, проте при великій кількості запитів та повільній роботі накопичувача можливі затримки.
При роботі з базою даних MS SQL або Postgresql при такому сценації 2 чеки будуть проводитись одночасно як і можуть одночасно виконуватись інші запити. -
ПРРО, принтера та термінали як окремі пристрої в ДМ передбачають виключно синхронний режим роботи по запитам на ендпоінти
/dm/execute,/dm/execute-prnта/dm/execute-pkg.
Це означає що API запити з 2-х і більше місць одночасно на одну касу, принтер чи термінал оброблюватись не будуть.
Запит який дійшов перший - буде оброблюватись, на всі наступні запити до завершення першого буде повернуто помилку з кодом 1105:
{
"ver": 6,
"resp_ver": 4,
"source": "",
"device": "postgres1",
"tag": "",
"task_status": 3,
"type": 1,
"task": 1,
"dt": "20250725075425311",
"res": 1105,
"res_action": 1,
"errortxt": "Пристрій зайнятий",
"aq_errortxt": "",
"warnings": []
}
При роботі з ПРРО по наступному запиту буде повертатись одразу помилка з кодом 1105 в той час як по терміналам та принтерам реалізовано функціонал міні-черги: якщо за 15 секунд перший запит по терміналу або принтеру не завершено, тільки тоді буде повернуто помилку, у випадку завершення раніше - запит буде виконано.
Що стосується інших ендпоінтів окрім /dm/execute, /dm/execute-prn та /dm/execute-pkg API запити по ним виконуються паралельно і не видають помилку з кодом 1105, проте повертаючись до першого пункту, у разі використання SQLite абсолютно всі запити які повертають якусь інформацію про ПРРО, чеки, термінал чи принтер, редагування налаштувань та фіскалізація чеку будуть виконуватись згідно внутрішньої черги.
¶ Транзакційний режим
При роботі з ПРРО рекомендовано реалізувати транзакційний режим для забезпечення цілісності даних між обліковою програмою та ДМ.
Основна ціль даного функціоналу в можливості повторно отримати результат уже проведеного чеку або точно переконатись що чеку із заданим значенням унікального ключа не було створено раніше.
Це потрібно для випадків коли:
- Облікова система не змогла отримати відповіді від Device Manager по ряду причин (таймаути, раптове вимкнення живлення пристрою тощо).
- Облікова система має потребу зробити звірку по операціям чи всі були проведені.
Також транзакційний режим можна використовувати при роботі з терміналами окремо від ПРРО. Покриває даний режим ті ж самі випадки що і при роботі з ПРРО.
¶ Транзакційний режим при роботі з ПРРО
- Робота в транзакційному режимі з ПРРО здійснюється за допомогою передачі значення унікального ключа для запиту в корені API запиту в ключ
"tag".
"tag"- має мати унікальне значення для кожного нового запиту на фіскалізацію в рамках кожного ПРРО створеного в ДМ. Максимальна довжина 200 символів.
Наприклад маємо ситуацію:
Облікова система відправляє чек з "tag": "b57f3011-1d42-47f1-8690-e9e0ea65df45"
ДМ перед фіскалізацією чеку перевіряє чи немає в проведеного раніше чеку з tag b57f3011-1d42-47f1-8690-e9e0ea65df45
Якщо немає - відбувається фіскалізація нового чеку.
Якщо було знайдено - повертається з відповідь з інформацією про фіскалізований раніше чек, фіскалізації не відбувається.
Звертаємо увагу що по значенню
tagповторно можна отримати лише успішно виконані операції, тобто успішно створені чеки чи звіти.
Коли потрібно лише перевірити наявність фіскалізованого чеку із зазначеним tag без фіскалізації, якщо чек не було знайдено - в корінь JSON запиту передається "type": 0 замість "type": 1, можна також передавати скорочений JSON без зазначення "type": 0 (скорочений JSON підійде у випадку якщо потрібно лише отримати дані по чеку без його друку на принтері)
наприклад:
curl --location 'http://localhost:3939/dm/execute' \
--header 'Content-Type: application/json' \
--data '{
"device": "postgres1",
"tag": "DC7A45F1-41BF-4AFE-B072-7CC2CBA282F0"
}'
Якщо по касі з назвою postgres1 чек з значенням tag DC7A45F1-41BF-4AFE-B072-7CC2CBA282F0 було знайдено - буде повернуто повну відповідь по цьому чеку із значенням "task_status": 2
Якщо його не було знайдено - буде наступна відповідь:
{
"ver": 6,
"resp_ver": 4,
"source": "",
"device": "postgres1",
"tag": "DC7A45F1-41BF-4AFE-B072-7CC2CBA282F0",
"task_status": 3,
"type": 0,
"task": -1,
"dt": "",
"res": 1058,
"res_action": 1,
"errortxt": "Чек з кодом синхронізації DC7A45F1-41BF-4AFE-B072-7CC2CBA282F0 не знайдено",
"aq_errortxt": "",
"warnings": []
}
- Кожен чек з цього списку буде обов'язково мати tag.
-відкриття зміни ("task": 0)
-чек на продаж ("task": 1)
-чек на повернення ("task": 2)
-внесення/видача ("task": 3,"task": 4)
-Z-звіт ("task": 11)
-чек видачі готівки ("task": 14)
-чек переказу коштів та видачі коштів при переказі ("task": 15,"task": 16)
Так як tag обов'язково є у кожного з перерахованих вище завданнь, якшо його не передано в JSON запиті наприклад на чек продажу, ДМ сформує його сам у форматі uuid і поверне у відповідь.
Тип відправленого завдання, додатково до значення tag, не перевіряється. Тобто якщо раніше був сформований чек продажу ("task": 1) з "tag": "b57f3011-1d42-47f1-8690-e9e0ea65df45", а пізніше відправлено запит на повернення ("task": 2) чи на формування Z-звіту ("task": 11) з цим же значенням tag, ДМ у відповідь на ці завдання поверне сформований раніше чек.
Всі інші операції не мають tag - виконуються кожного разу з новими даними, тому реалізація повторних запитів з використанням tag для них не потрібна.
- Для розуміння того що відбулось з чеком ДМ у відповідь в корені JSON повертає ключ "task_status"
Значення наступні:
1 - чек чи звіт фіскалізовано, або завдання виконано якщо tag там не підтримується.
2 - знайдено чек в БД і повернуто відповідь по tag
3 - помилка при фіскалізації чеку чи при виконанні завдання, при цьому значення"res"завжди буде більше 0.
¶ Обробка можливих помилок.
Визначення коли краще робити повторний запит, а коли можна бути точно впевненим що чек фіскалізовано можна робити наступним чином:
- Робити повторний запит з тим же значенням tag якщо не було отримано відповіді по API з певних причин.
- Якщо відповідь було отримано, проте завдання не завершилось успішно (чек не було фіскалізовано) - орієнтуватись на значення
"res_action".
Значення "res_action" можуть бути наступні:
0 - Завдання пройшло. Означає успішне виконання завдання ДМ-ом, наприклад чек чи звіт фіскалізовано, при цьому значення "res" в даному випадку завжди буде рівним 0.
1 – Помилка при проведенні завдання, завдання не пройшло, наприклад чек не було фіскалізовано із за помилки підписання і ПРРО не може, з певних причин, перейти в офлайн режим, при цьому значення "res" в даному випадку завжди буде більше 0. Можна повторити запит з тим же значенням tag.
Приклад відповіді:
{
"ver": 6,
"source": "",
"device": "postgres1",
"tag": "97052EA9-1837-48DE-81EE-FB82478211D6",
"task_status": 3,
"type": 1,
"task": 0,
"dt": "20230906171959722",
"res": 1069,
"res_action": 1,
"errortxt": "Виникла помилка при підписанні контенту електронним підписом: Помилка підписання даних у рядку. Виникла помилка при отриманні позначки часу. TSP-сервер не доступний (проблеми з комунікаційними засобами) або не пройдено автентифікацію на proxy-сервері(65)",
"aq_errortxt": "",
"warnings": []
}
2 - Помилка + колізія. Колізія може виникнути у випадку якщо чек було відправлено, але не отримано відповіді про те чи цей чек було фіскалізовано (або отримано помилку) та ПРРО не може, з певних причин, перейти в офлайн режим. Виправлення колізії відбувається автоматично при відправці будь-якого наступного завдання, але для збереження транзакційності рекомендується виконати повтор останнього завдання з тим же значенням tag. Значення "res" в даному випадку завжди буде більше 0.
Приклад відповіді:
{
"ver": 6,
"resp_ver": 1,
"source": "",
"device": "postgres1",
"tag": "EC53AAA2-B327-4F4A-AADE-3ACCC29824BA",
"task_status": 3,
"type": 1,
"task": 2,
"dt": "20240507190920264",
"res": 1121,
"res_action": 2,
"errortxt": "Дата на пристрої не співпадає з поточною датою на сервері. (Status: 0; У чеці вказано час у майбутньому. Фіскалізувати такий чек неможливо. Будь ласка, виправіть час на вашому девайсі та повторіть спробу.; )",
"aq_errortxt": "",
"warnings": []
}
3 - Помилка, потрібне коригування даних. Може бути помилка у відправлених в запиті даних, помилка виконання операції із за статусу в якому знаходиться ПРРО або помилка в самому застосунку, яку потрібно вирішувати через техпідтримку, при цьому значення "res" в даному випадку завжди буде більше 0. В даному випадку без виправлення вхідних даних або вирішення помилки - повторний запит ситуації не змінить.
Приклад відповіді:
{
"ver": 6,
"source": "",
"device": "Test1",
"tag": "C473FEE9-4B6C-41E7-97AA-9B29C50A3C42",
"task_status": 3,
"type": 1,
"task": 1,
"dt": "20230906171629056",
"res": 1092,
"res_action": 3,
"errortxt": "Зміна по даному ПРРО закрита. Для фіскалізації чеків необхідно відкрити зміну.",
"aq_errortxt": "",
"warnings": []
}
¶ Транзакційний режим при роботі банківськими терміналами
Дана інформація відноситься до API роботи з терміналами, роботи ПРРО в пакетному режимі даний функціонал не стосується.
При відправці запитів на банківський термінал також доступний транзакційний режим проте в даному випадку він працює дешо інакше як з ПРРО та поділяється на 2 можливості:
- Синхронізація даних мід обліковою/касовою програмою по раніше проведеним операціям
- Отримання напряму з терміналу статусу конкретної операції.
¶ Синхронізація даних мід обліковою/касовою програмою по раніше проведеним операціям
Для роботи в даному режимі обов'язково використовується 2 ключа:
transaction_id- UUID (v5). Ідентифікатор транзакції що використовується як мітка для завдання для пошуку при повторному запиті. Якщо передати значення відмінне від UUID формату, воно буде замінено на UUID що згенерував ДМ та повернуто у відповідь.transaction_search- Параметр дій з пошуком транзакції.
0 - Пошук транзакції не відбувається, запит одразу йде на термінал.
1 - Пошук транзакції перед відправкою даних на термінал. Якщо знайдено, буде повернуто json у відповідь на запит. Якщо транзакцію не було знайдено в БД буде повернуто відповідь що такої транзакції неіснує і дії пов'язані з цією транзакцією(оплата, повернення, скасування) не будуть відправлені на термінал.
2 - Пошук транзакції перед відправкою даних на термінал. Аналогічно 1, за виключенням того, якщо транзакцію не було знайдено в БД запит буде відправлено на термінал.
За замовчуванням = 0
transaction_id може бути не унікальним навідміну від tag який є завжди унікальним. В такому випадку у разі наявності в базі даних 2-х і більше операцій з однаковим значенням transaction_id буде повертатись остання по даті.
Розберемо на прикладі:
ДМ має збережені дані про проведену оплату на терміналі із значенням transaction_id рівним f535206e-fe64-11ef-bfc2-00505680badb проте облікова/касова програма не має інформації про цю операцію, лише збережений transaction_id.
- У випадку передачі в запиті:
"transaction_id": "f535206e-fe64-11ef-bfc2-00505680badb"
"transaction_search": 0
Відбудеться відправка запиту на термінал на нову оплату.
- У випадку передачі в запиті:
"transaction_id": "f535206e-fe64-11ef-bfc2-00505680badb"
"transaction_search": 1
Так як така транзакція уже існує - буде повернуто всю інформацію про дану транзакцію без відправки запит на термінал.
- У випадку передачі в запиті:
"transaction_id": "f535206e-fe64-11ef-bfc2-00505680badb"
"transaction_search": 2
Аналогічно попередньому так як така транзакція уже існує - буде повернуто всю інформацію про дану транзакцію без відправки запит на термінал.
- У випадку якщо в запиті не передано ключів
transaction_idтаtransaction_searchвідбудеться відправка запиту на термінал.
Звертаємо увагу що навідміну від ПРРО, по терміналам зберігається результат виконання операції, тобто можуть як успішні оплати чи інші операції так і помилки при з'єднанні з терміналом або помилки від самого терміналу.
Кожна операція з цього списку буде обов'язково мати transaction_id.
1) Оплата ("task": 1)
2) Повернення по оплаті("task": 2)
3) Скасування операції на терміналі ("task": 3)
4) P2P переказ ("task": 4);
5) Універсальний сервіс. ("task": 5);
6) Запит на зчитування карти з подальшим очікуванням підтвердження/корекцією. ("task": 6);
7) Завершення запиту підтвердження/корекції ("task": 7);
8) Зчитування дисконтної карти ("task": 8);
9) X-Баланс. Друк підсумків без закриття батчу. ("task": 10);
10) Загальний звіт. Закриття батчу та друк підсумків. ("task": 11);
11) Видача коштів. Оплата товару/послуги + видача готівки. ("task": 14);
12) Оформлення оплати частинами. ("task": 15);
13) Повернення по оплаті частинами. ("task": 16);
14) Отримання проведеної раніше операції по терміналу або отримання останньої операції ("task": 17).
Тип відправленого завдання, додатково до значення transaction_id, не перевіряється, так само як і в ПРРО.
Всі інші операції (наприклад отримання списку мерчантів) не мають transaction_id - виконуються кожного разу з новими даними, тому реалізація повторних запитів для них не потрібна.
¶ Отримання напряму з терміналу статусу конкретної операції.
Для цього використовується окремий функціонал отримання проведеної раніше операції по терміналу або отримання останньої операції ("task": 17).
¶ Транзакційний режим при роботі в пакетному режимі
При роботі в пакетному режимі також допускається і рекомендується використання ключа tag, але при цьому не використовуються значення transaction_id та transaction_search як при роботі з терміналами окремо.
Процес виглядає наступним чином:
- Перевірка значення переданого в ключі
tagна співпадіння з раніше проведеними операціями по ПРРО. - Якщо знайдено - повертається інформація по чеку до облікової системи, при цьому якщо в чеку вказана оплата картою запит на термінал не відбувається, але відбудеться друк чеку (якщо підключено принтер). Друк чеку можна пропустити передавши в корінь JSON body запиту значення
"skipprint": true. - Якщо не знайдено відбувається запит на термінал на оплату (якщо його підключено та в чеку вказана оплата картою), фіскалізація чеку та його друк (якщо підключено принтер).
¶ Збереження чеків
Звертаємо увагу що по ключам tag для ПРРО та transaction_id для терміналів можна отримати лише дані які збережені локально в базі даних Device Manager, якщо локально даних немає - їх буде не можливо отримати.
Стандартно чеки зберігаються за останні 40 днів, а операції з терміналами за останні 90 днів.
Налаштуваннями часу збереження можна керувати через сторінку налаштування в ДМ.
Не рекомендовано зберігати локально чеки за тривалий період так як це може призвести до сповільнення роботи ПРРО на великого розміру базах даних та слабких дисках. Всі чеки за замовчуванням будуть доступні у кабінеті Вчасно.Каса для перегляду.
¶ Типізація даних в JSON
Рекомендовано дотримуватись передачі значень в JSON body запиту у типі даних визначеному в описі API. Наприклад якщо передбачається JSON number значення для параметру "sum" значення має бути, наприклад, 23.44.
При серіалізації/десеріалізації JSON при обробці запиту всередині застосунку можливі наступні варіації:
- Якщо значення string - очікується як вхідні дані string значення. Також наприклад number значення, наприклад 24.33 може конвертуватись в string
"24.33"без помилок. Пусте значення можна передавати через"". - Якщо значення number - очікується як вхідні дані число максимум 2 або 3 знаки після коми (залежно від ключа в JSON). Також наприклад string значення, наприклад "24.33" (тільки з роздільником
.) може конвертуватись в number24.33без помилок. - Якщо значення object (JSON об'єкт) - очікується як вхідні дані об'єкт. Також при передачі null якщо об'єкт не містить даних не викличе помилки.
- Якщо значення array - очікується як вхідні дані масив. Порожній масив що не містить даних можна передати як
[] - Якщо значення boolean - очікується як вхідні дані true або false. Також можливо передавати number значення 0 - що дорівнює false і 1 - що дорівнює true.
Якщо передати будь яке інше значення, наприклад в "code_aa": "" коли для code_aa очікується array - це викличе помилку.
Звертаємо увагу що всі інші значення з плаваючою комою (float до 2 або 3 знаків після коми) з JSON відповіді з версії 7.0 повертаються з залишком 0 після коми, тобто було
"cnt": 2, а стало"cnt": 2.0. Необхідно врахувати це у касовій програмі якщо такі зміни у вас можуть призвести до проблем з обробкою відповідей.
¶ Перелік кодів та текстів помилок
¶ ДМ
Тут вказано список можливих помилок при роботі ДМ, включаючи загальні помилки при роботі з пристроями.
| Код(res) | Текст помилки(errortxt) | Додаткова інформація |
|---|---|---|
| 430 | Device error: %s | Помилка при роботі з пристроєм. При отриманні рекомендовано звернутись до техпідтримки. |
| 1016 | Internal error: | Внутрішня помилка з додатковим описом. При отриманні рекомендовано звернутись до техпідтримки. |
| 1091 | Пристрій не знайдено | Пристрою з вказаною в запиті назвою(device) не існує в ДМ. Потрібно перевірити коректність назви. |
| 1105 | Пристрій зайнятий | Пристрій виконує попереднє завдання, додатком блокується виконання по одному пристрою завдань паралельно для уникнення помилок в роботі. Рекомендовано почекати закінчення виконання попереднього завдання перед відправкою нового. |
| 1082 | Неможливо зберегти дані до бази даних. | Повертаєтсья у випадку якщо додаток запущено без прав адміністратора або пошкоджено базу даних. Рекомендовано звернутись на техпідтримку для вирішення. |
¶ ПРРО
Тут вказано список можливих помилок при роботі з ПРРО.
| Код(res) | Текст помилки(errortxt) | Додаткова інформація |
|---|---|---|
| 307 | Некоректний номер завдання роботи з ПРРО task: %d | У запиті у fiscal.task вказано непідтримуваний номер завдання, потрібно вказати кореткний номер і повторити запит. |
| 1006 | Зміна по даному ПРРО була закрита. Повторне закриття неможливе | |
| 1032 | ДПС: помилка перевірки підпису чеку, із за збою в роботі податкової чи АЦСК вашого ключа ЕЦП. | |
| 1033 | ДПС: Помилка перевірки ПРРО | Повертається у випадку отримання від ДПС помилки про використання різних ключів ЕЦП в одній зміні або при відкритті змін якщо зміна уже відкрита. При отриманні рекомендовано звернутись до техпідтримки. |
| 1034 | ДПС: Помилка запису чеку. | Повертається у випадку отримання від ДПС помилки про неможливість запису чеку. При отриманні рекомендовано звернутись до техпідтримки. |
| 1035 | ДПС: Загальна помилка | При отриманні рекомендовано звернутись до техпідтримки. |
| 1036 | ДПС: Помилка типу відправки | Повертається у випадку отримання від ДПС помилки при відкритті зміни що ПРРО заблоковано. При отриманні в процесі роботи ПРРО може означати спробу перейти в режим офлайн якщо ПРРО знаходиться в режимі офлайн і навпаки. При отриманні рекомендовано звернутись до техпідтримки. |
| 1037 | ДПС: Відсутній Z-звіт з попереднім порядковим номером | При отриманні рекомендовано звернутись до техпідтримки. |
| 1038 | ДПС: Некоректний формат XML | При отриманні рекомендовано звернутись до техпідтримки. |
| 1039 | ДПС: Некоректна дата. Дата в XML чеку не відповідає даті чеку. Check.date | При отриманні рекомендовано звернутись до техпідтримки. |
| 1040 | ДПС: Некоректні дані в XML або структурі чеку | При отриманні рекомендовано звернутись до техпідтримки. |
| 1041 | ДПС: Невірний формат Z-звіту | При отриманні рекомендовано звернутись до техпідтримки. |
| 1042 | ДПС: ПРРО заблоковано. Перевищено ліміт роботи в оффлайні в 168 годин на місяць | При отриманні рекомендовано звернутись до техпідтримки. |
| 1043 | ДПС: Некоректний хеш останнього чеку. Порушено послідовність передачі чеків до контролюючого органу | Повертається у випадку отримання від ДПС помилки про порушення послідовності переачі чеків. Може означати що по ПРРО видавались чеки через іншого провайдена ПРРО, касу було перенесено з іншого ДМ або сталась помилка на стороні ДПС. При отриманні рекомендовано звернутись до техпідтримки. |
| 1044 | ДПС: ПРРО не зареєстровано або стався збій на стороні податкової | При отриманні рекомендовано звернутись до техпідтримки. |
| 1045 | ДПС: Не зареєстровано ключ ЕЦП для підписання чеків або стався збій на стороні податкової. Потрібно його зареєструвати заповнивши заявку через кабінет Вчасно.Каса, або форму №5ПРРО через кабінет податкової, або дочекатись відновлення роботи кабінету ДПС | Повертається у випадку отримання від ДПС помилки що ключ ЕЦП не зареєстровано. Потрібно зареєструвати ключ ЕЦП або, якщо ключ зареєстровано, дочекатись відновлення роботи ДПС. |
| 1046 | ДПС: Помилка при закритті зміни. Зміна по ПРРО не відкрита в ДПС | Повертається у випадку закриття зміни та отримання від ДПС помилки що зміна наразі не відкрита. При отриманні рекомендовано звернутись до техпідтримки. |
| 1047 | ДПС: Некоректний номер фіскального чеку виданого в режимі offline або спроба відправити чек виданий в режимі online при роботі ПРРО в режимі offline. | При отриманні рекомендовано звернутись до техпідтримки. |
| 1048 | Невідома помилка Вчасно | Помилка отримана від кабінету Вчасно.Каса. У випадку отримання даної помилки рекомендовано звернутись до техпідтримки. |
| 1049 | Невірний хеш останнього чеку | Помилка отримана від кабінету Вчасно.Каса. У випадку отримання даної помилки рекомендовано звернутись до техпідтримки |
| 1050 | Немає доступу до серверу ДФС | |
| 1051 | Чек з кодом синхронізації %s було знайдено в БД. Відповідь була відправлена повторно. | До кореня запиту у tag було передано раніше використаний ідентифікатор для іншого чеку. |
| 1052 | ПРРО заборонено переходити в режим оффлайн. | Неможливо перейти в офлайн так як в налаштуваннях ПРРО не дозволено перехід в офлайн. |
| 1053 | Неможливо перейти в оффлайн знаходячись в оффлайні. | Повертається у випадку спроби перейти в офлайн якщо ПРРО наразі знаходиться в режимі офлайн. |
| 1054 | Неможливо перейти в онлайн знаходячись в онлайні | Повертається у випадку спроби перейти в онлайн якщо ПРРО наразі знаходиться в режимі онлайн. |
| 1056 | Відсутні оффлайн номери для роботи ПРРО в режимі оффлайн. Отримання номерів, від ДПС, буде здійснено автоматично, після успішного відкриття зміни в режимі онлайн. | Для ПРРО не отримано список офлайн номерів від ДПС. Рекомендовано перевідкрити зміну. |
| 1058 | Чек з кодом синхронізації не знайдено | Повертаєтсья у випадку пошуку завдання по tag якщо завдання з переданим в запиті tag не було знайдено в БД. |
| 1059 | В заданому діапазоні Z-звітів не знайдено | Повертається у випадку якщо в запиті для завдань 12 та 13 передано некоректний діапазон вибірки періодичних звітів, або даних за вказаний період немає |
| 1060 | Виникла помилка при формуванні зведеного Z-звіту: звіт, з локальним номером, пошкоджений | Повертається для завдань 12 та 13 якщо у вибраному діапазоні є пошкоджений звіт. В такому разі формування зведеного звіту з заданими параметрами неможливе. |
| 1062 | ПРРО знаходиться в режимі оффлайн більш ніж 35 годин. Дозволено тільки закриття зміни(11) | ПРРО працює в офлайн режимі понад встановлену кількість годин. Рекомендовано звернутись до техпідтримки для уточнення причин. |
| 1063 | Для чеку внесення/видачі грошей сума не може бути від`ємною | |
| 1064 | Для прибуткового/видаткового чеку сума не може бути від`ємною | |
| 1065 | Для прибуткового/видаткового чеку решта в оплаті з індексом %d не може бути від`ємною | |
| 1066 | Для прибуткового/видаткового чека в оплаті з індексом %d обов`язкові для заповнення поля: paysys, rrn и cardmask | |
| 1067 | Пустий ідентифікатор зміни. Повторіть спробу реєстрації чека | |
| 1069 | Виникла помилка при підписанні контенту електронним підписом: | Повертається у випадку помилки підписання чеку ключем ЕЦП. Після ":" буде додано текст помилки бібліотеки підписання. |
| 1073 | Попередній чек в статусі "Непроведений". Потрібне ручне втручання | Рекомендовано звернутись до техпідтримки для вирішення проблеми. |
| 1074 | Неможливо вирішити колізію. Потрібне ручне втручання | Рекомендовано звернутись до техпідтримки для вирішення проблеми. |
| 1075 | Колізія не виправлена. Неможливо отримати останній проведений чек. | Помилка при отриманні останнього чеку. Можлива проблема з доступом до кабінету Вчасно.Каса, до АЦСК або збій зі сторони ДПС. |
| 1076 | Сума базових сум податків не співпадає з сумою оплат. | Рекомендовано звернутися до служби підтримки для вирішення ситуації. |
| 1077 | У касі недостатньо коштів для проведення даної операції | Повертається для завдань 2, 4, 14 при оплаті готівкою якщо по ПРРО не достатньо залишку готівки для проведення завдання. |
| 1078 | Для ПРРО "%s" не заповнені типи податків | |
| 1079 | Для податкової групи %s не підтримується %s алгоритм розрахунку | |
| 1080 | В БД є колізія. Вхідний JSON відрізняється від надісланого раніше. | |
| 1081 | Виникла помилка при формуванні X-звіту. | Повертаєтсья для завдання 10 у випадку якщо немає даних для формування X-звіту або виникла інша помилка при його формуванні. |
| 1082 | Неможливо зберегти дані до бази даних. | Пошкоджено базу даних, з якою взаємодіє Device Manager. Для діагностики рекомендовано звернутися до тех. підтримки Вчасно.Каса. |
| 1083 | Неможливо отримати налаштування по ПРРО. Спробуйте замінити токен Вчасно.Каса | В додатку внесено некоректний токен для ПРРО, потрібно згенерувати новий в кабінеті Вчасно.Каса та замінити в додатку. |
| 1084 | Сервіс ДПС недоступний | |
| 1085 | Запит на перехід в режим онлайн виконати неможливо. Пристрій знаходиться в режимі онлайн | |
| 1086 | Виникла помилка при формуванні Z-звіту. | Рекомендовано звернутись до техпідтримки для вирішення проблеми. |
| 1087 | Невірний тип податкової групи "%s" | |
| 1088 | Невірний тип оплати "%s" | |
| 1089 | Позиція %d: %s містить заборонений символ | Для успішного завершення запиту необхідно прибрати заборонений символ. |
| 1090 | Неможливо розрахувати %s | |
| 1090 | Неможливо розрахувати %s | |
| 1091 | Пристрій не знайдено | |
| 1092 | Зміна по даному ПРРО закрита. Для фіскалізації чеків необхідно відкрити зміну. | |
| 1093 | Фіскальний номер пристрою пустий | |
| 1094 | Приватний ключ ЕЦП не завантажено | Для вирішення помилки варто звернутися до тех. підтримки Вчасно.Каса. |
| 1095 | Для пристрою не налаштовані параметри роботи з ЕЦП | Потрібно завантажити ключ ЕЦП до ПРРО. |
| 1096 | Зміна по даному ПРРО уже була відкрита. Повторне відкриття неможливе | |
| 1097 | Список товарів пустий | Попертається для завдань 1, 2 якщо передано суму до оплати, але пустий список товарів. |
| 1098 | Об`єкт "%s" пустий | Необхідно перевірити об'єкт, що відображається замість "%s" у JSON-тілі запиту та заповнити його згідно опису API. |
| 1099 | Z-звіт вже відправлено | |
| 1100 | Потрібно закрити зміну | |
| 1101 | Сума чеку не співпадає з сумою по позиціям | Повертається у випадку якщо сума(sum) всіх позицій(в масиві fiscal.receipt.rows) з урахуванням знижок(disc) на кожну з позицій не співпадає з сумою по чеку(fiscal.receipt.sum). |
| 1102 | Сума чеку не співпадає з сумою по оплатам | Повертається у випадку якщо сума по чеку(fiscal.receipt.sum) з урахуванням знижки на весь чек(fiscal.receipt.disc) не співпадає з загальною сумою по оплатам в чеку(fiscal.receipt.pays). |
| 1103 | Не заповнена назва товару | |
| 1107 | Ціна помножена на кількість, відрізняється більш ніж на 1 від суми позиції | Повертається у випадку якщо ціна товару помножена на кількість дорівнює нулю. |
| 1108 | Знижка відрізняється менше ніж на 1 від суми позиції | Повертається у випадку якщо знижка на товар рівна сумі товару. Мінімальна ціна за товар після знижки має бути не менше 0.01грн. |
| 1109 | Сума по типу оплати %s дорівнює 0 | Повертається у випадку якщо сума оплати по одному із типів оплат в чеку рівна 0. |
| 1110 | %s не відповідає жодній з глобальних | Повертається у випадку якщо тип оплати або податкова група яка наявна в чеку не включена в налаштуваннях ПРРО. %s буде замінено на цифрове позначення групи чи типу оплати. |
| 1111 | Код товару %s було продано раніше по податковій групі %s(%s) | Повертається у випадку якщо код товару в чеку в поточній зміні було раніше продано з іншою податковою групою. %s буде замінено на код товару та позначення податкової групи. Рекомендовано змінити код товару або податкову групу для даного товару або перевідкрити зміну. |
| 1112 | Сума заокруглення повинна бути в межах від -0.99 до 0.99 | |
| 1115 | Для ПРРО не налаштовані параметри роботи із заокругленням | В типах оплат для ПРРО не включено "Заокруглення". |
| 1117 | Неможливо перейти в режим оффлайн, строк дії приватного ключа закінчується | Повертається у випадку якщо ключ ЕЦП закінчується менше як за 3 дні і сталась помилка при які була спроба перейти в режим офлайн. Для уникнення проблем перехід в офлайн в таких випадках блокується. |
| 1119 | Чек "Видачі коштів" не може бути с типом оплати "Готівка" | Повертається для завдання 14 у випадку якщо тип оплати передано не "Картка". |
| 1120 | Комісія в чеку "Видачі коштів" не може бути меньше 0 | |
| 1121 | Дата на пристрої не співпадає з поточною датою на сервері. | Повертається у випадку розбіжності в +30хв в даті на пристрої та на сервері Вчасно.Каса. Потрібно відкоригувати дату на пристрої та перезапустити його. |
| 1122 | Закінчились оффлайнові номери для роботи ПРРО в режимі оффлайн. Було використано всі номери для чеків під час роботи в оффлайні. Отримання номерів буде здійснено автоматично після успішної реєстрації оффлайнових чеків та переходу до режиму онлайн. | Повертається у випадку роботи в режимі офлайн якщо було використано всі отримані від ДПС офлайн номери. |
| 1123 | Недостатньо коштів на балансі. Поповніть рахунок та повторіть спробу проведення чеку: https://kasa.vchasno.ua/app/company/settings/balance-info | Повертається у випадку якщо ПРРО заблоковано із за відсутності коштів на балансі. Потрібно поповнити рахунок на суму тарифу та повторити спробу провести чек. |
| 1124 | Для ПРРО "%s" був виконаний метод аварійної заміни ЕЦП, дозволено тільки закриття зміни(11) | Повертається у випадку якщо було замінено ключ на відкритій зміні по ПРРО. Заблоковано проведення чеків та перехід в офлайн. Потрібно виконати z-звіт. |
| 1125 | Ви використовуєте застарілу версію Device Manager. Дана версія додатку більше не підтримується! Для того щоб видавати чеки оновіть додаток до актуальної версії. Процес оновлення: https://wiki-kasa.vchasno.ua/uk/DeviceManager/Maintenance/Update | Повертається у випадку якщо встановлена версія додатку більше не підтримується. Необхідно оновити додаток до актуальної версії. |
| 2000 | Невірний формат вхідного JSON | Повертається у випадку якщо в запиті передано дані не в форматі json або в структурі json запиту наявна помилка. |
| 2001 | Невірний/недійсний токен Вчасно.Каса для даного ПРРО | Повертається у випадку створення ПРРО в додатку з недійсним токеном. Рекомендовано згенерувати токен та повторити спробу створити ПРРО. |
| 2002 | ПРРО з такою назвою вже зареєстровано | Повертається у випадку створення ПРРО з назвою яка уже наявна в додатку. Необхідно придумати унікальну назву. |
| 2003 | Помилка при зчитуванні особистого ключа ЕЦП: %s | Помилка при зчитуванні ключа ЕЦП. Замість %s буде повернуто детальну помилку від бібліотеки підписання. |
| 2005 | Помилка доступу до сервісу Вчасно | Повертається у випадку якщо з пристрою де встановлено додаток немає доступу до кабінету Вчасно.Каса(kasa.vchasno.ua) |
| 2007 | ПРРО з ІД %s не знайдено | Повертається у випадку роботи з розширеним API для налаштування і переглянду інформації ПРРО якщо по переданому в запиті ідентифікатору не було знайдено ПРРО. |
| 2009 | Неможливо змінити ЕЦП: пристрій з ІД %s використовується | Повертається у випадку роботи завантаження ЕЦП до ПРРО якщо відкрита зміна або виконується інше завдання. |
| 2011 | ПРРО з ІД %s не використовується | Повертається у випадку спроби виконати завдання по ПРРО яке вимагає ініціалізації ПРРО. Рекомендовано спробувати відкрити зміну і повторити дію. |
| 2013 | ПРРО з ІД %s знаходиться в режимі оффлайн | Повертається у випадку спроби виконати дію яка заборонена до виконання при знаходженні ПРРО в режимі офлайн. |
| 2014 | ПРРО не налаштовано, перевірте. | Повертається у випадку створення ПРРО по якому не встановлено податкові групи та види оплат. |
¶ Термінали та термінали у смартфоні
Тут вказано список можливих помилок при роботі ДМ з терміналами та tap2phone та опис специфічних протоколам помилок.
¶ Загальні помилки при роботі або з'єднанні з терміналами
| Код(res) | Текст помилки(errortxt) | Додаткова інформація по помилці |
|---|---|---|
| 303 | Protocol id="%s", name="%s" do not recognised | Для службових завдань по терміналу. Помилка пошуку протоколу по назві пристрою. потрібно перевірити чи коректно передано назву пристрою(dev_name) в параметрах запиту. |
| 317 | Некоректний номер завдання роботи з терміналами task: %d | У запиті у pay.task вказано непідтримуваний номер завдання. Потрібно вказати кореткний та повторити запит. |
| 411 | Error receiving TimeOut: %d ms | Таймаут з'єднання з терміналом при виконанні завдання. Основна відмінність від Interface init error в тому що термінал отримав запит, але перевищено час очікування відповіді від терміналу. |
| 1016 | Internal error: Connection Closed Gracefully | Розрив з'єднання з терміналом(з боку терміналу). Завичай відбуваєтсья при відправці на термінал запиту з іншого ДМ коли термінал опрацьовує попереднє завдання. В такому випадку термінал може успішно виконати операцію, але ДМ відповіді не отримає. |
| 1126 | Неможливо відкрити СОМ порт. Порт відсутній в системі або зайнятий. | Помилка для терміналів Приватбанку. Повертається у випадку якщо COM порт відсутній в системі або порт зайняла/відкрила інша програма. |
| 5013 | Транзакцію з id="%s" не знайдено в БД | Повертається у випадку відправки запиту на термінал з transaction_search = 1 коли транзакцію не знайдено. %s буде замінено на значення id транзакції переданої в запиті. |
| 5028 | Неможливо встановити з'єднання з терміналом по інтерфейсу %s (%s) | Загальна помилка для терміналів Ощадбанку, Укрсиббанку, Райффайзенбанку та Банку Восток. Зазвичай означає помилку з'єднання з терміналом. Термінал або недоступний або некоректно вказано IP адресу чи COM порт. %s буде замінено на значення поточного інтерфейсу та параметрів підключення. |
| 5029 | Термінал %s (%s) не підтримує завдання з типом %s | Загальна помилка для всіх терміналів. Означає що вкзаний в запиті тип завдання (наприклад Оплата частинами) не підтримуєтсья для даного банку та терміналу. %s буде замінено на назву терміналу, протокол та номер завдання. |
| 5067 | Помилка при з'єднанні за вказаною адресою: %s | Помилка для терміналів Приватбанку. Повертається у випадку якщо термінал недоступний по IP адресу та порту. |
| 5068 | Таймаут при перевірці зв'язку з терміналом | Помилка для терміналів Приватбанку. Якщо підключення через Ethernet або COM було встановлено з'єднання по ip адресу та порту або успішно відкрито COM порт, але при перевірці зв'язку з терманлом(при встановленні хендшейку по протоколу) не було отримано відповіді від терміналу. |
¶ При роботі з терміналами по протоколу PrivatBankJSON
| Код(res) | Текст помилки(errortxt) | Додаткова інформація |
|---|---|---|
| 5000 | Помилка терміналу: %s | Помилка отримана від терміналу, Помилка може бути як в самому терміналі так і отримана від хосту(банку). %s буде замінено на текст помилки що повертає термінал. |
| 5000 | Помилка терміналу: пристрій зайнятий | Помилка отримана від терміналу, якщо термінал опрацьовує попередній запит який отримав раніше. Необхідно дочекатись завершення виконання попереднього запиту і тоді відправляти новий. |
¶ При роботі з терміналами по протоколу BPOS1
| Код(res) | Текст помилки(errortxt) | Додаткова інформація |
|---|---|---|
| 5000 | Помилка терміналу: %s | Невідома помилка отримана від терміналу. |
| 5001 | Помилка терміналу: Операція скасована користувачем | Транзакцію скасовано користувачем на терміналі. |
| 5002 | Помилка терміналу: EMV Decline | |
| 5003 | Помилка терміналу: Transaction log is full. Need close batch | Переповнено журнал транзакцій, потрібно закрити, тобто виконати загальний звіт по терміналу. |
| 5004 | Помилка терміналу: Немає зв'язку з банком | Немає з'єднання з банком. |
| 5005 | Помилка терміналу: Немає паперу в принтері | Відсутній папір в принтері. |
| 5006 | Помилка терміналу: Error Crypto keys | |
| 5007 | Помилка терміналу: Card reader is not connected | |
| 5008 | Помилка терміналу: Transaction is already complete | |
| 5009 | Помилка терміналу: ResponseCodeStr = %s (не вдалося обробити помилку) | Невідома помилка від терміналу або не вийшло обробити помилку отриману від банку. Замість %s буде код помилки помилки отриманий від терміналу/банку. |
| 5010 | Помилка терміналу: error opening COM port | |
| 5011 | Помилка терміналу: need to open COM port | |
| 5012 | Помилка терміналу: error connecting with terminal | |
| 5014 | Помилка зв'язку з терміналом | Термінал доступний але при відправці забиту бібліотека не змогла встановити з'єднання з терміналом. Рекомендовано повторити останній запит так як він не пройшов. |
| 5015 | Повідомлення від банку: Відмова у проведенні операції | Відмова в проведенні операції від банку без опису причин. |
| 5016 | Повідомлення від банку: Недозволена сума трансакції | Недозволена сума для проведення оплати. |
| 5017 | Повідомлення від банку: Помилковий номер картки | Помилковий номер картки. Можна спробувати провести оплатку повторно, у разі поторення краще звернутись в банк. |
| 5018 | Повідомлення від банку: Недостатньо коштів на рахунку | Недостатньо коштів на рахунку клієнта для оплати. |
| 5019 | Повідомлення від банку: Невірний PIN | Некоректно введено PIN код для картки. |
| 5020 | Повідомлення від банку: Перевищено ліміт трансакці | Перевищено ліміт на оплати по карті |
| 5021 | Повідомлення від банку: Система не функціонує | Помилка на стороні банку, рекомендовано спробувати повторити запит на оплату. |
| 5022 | Помилка терміналу: Йде обробка попередньої операції | Повертаєтсья у випадку якщо термінал зайнятий обробкою попереднього запиту у разі відправки запиту з різних джерел(напиклад з 2 різних ДМ на один термінал). Рекомендовано зачекати закінчення і повторити запит. |
| 5025 | Повідомлення від банку: Некоректний RRN при виконанні повернення | Повертаєтсья у випадку якщо в запиті на повернення вказано некоректний rrn (refundid) оригінальної транзакції для виконання повернення. Рекомендовано перевірити коректнійсть введення rrn. |
| 5026 | Помилка терміналу: Потрібно виконати загальний звіт | Повертаєтсья у випадку якщо пройшло більше 24 годин (або інше значення встановлене банком) з моменту проведення першої транзакції по терміналу. Рекомендовано виконати загальний звіт на терміналі. |
| 5027 | Помилка терміналу: Операція не знайдена | Повертаєтсья у випадку якщо в запиті на скасування транзакції вказано некоректний номер транзакції (cancelid) для виконання скасування або було знято загальний звіт по терміналу і скасування більше не доступно. Рекомендовано перевірити коректність введення номеру. |
¶ При роботі з терміналами по протоколу POSAPI
| Код(res) | Текст помилки(errortxt) | Додаткова інформація |
|---|---|---|
| 5023 | Помилка терміналу: Операція скасована | Операція скасована користувачем кнопкою на терміналі врунку або самим терміналом у випадку помилки при обробці даних. |
| 5024 | Повідомлення від банку: %s Статус: %s Код відповіді банку: %s | Помилка отримана від банку при оплаті. Повертається в форматі: текст повідомлення, статус помилки, код відповіді банку. Приклад: Повідомлення від банку: ВIДМОВИТИ! Статус: 1 Код відповіді банку: 100 |
¶ Принтера та друк
| Код(res) | Текст помилки(errortxt) | Додаткова інформація |
|---|---|---|
| 100 | Помилка ініціалізації з'єднання. Connect timed out. | |
| 1016 | Internal error: Неможливо відправити на друк на принтер з даною назвою |