¶ 6.1.1 - patch від 28.02.2025
- Додали відображення валюти в рядку "Сума" в чеках на повернення.
¶ 6.1.0 - release від 28.02.2025
- Додано відображення рядка
Рештанавіть якщо сума решти = 0 у формі чеків на продаж. - Прибрано поля "Касир" та "Держатель ЕПЗ" при передачі в
fiscal.receipt.paysпараметра"show_additional_info": trueякий форсовано вмикав відображення для чеків на продаж та повернення. - Додано відображення необов'язкового рядка кількість товару, знак X, і ціну за одиницю навіть якщо кількість товару 1.
- Додано можливість використовувати термінали ingenico що працюють по протоколу
BPOS1як звичайні принтера чеків. При роботі через термінали ingenico будь якої моделі можна друкувати чеки та будь яку іншу інформацію як на принтері.
Робота з терміналом в режимі принтера нічим не відрізняється від роботи зі звичайним чекодруком в Device Manager. - Автопідбір АЦСК при зчитуванні файлового ключа тепер працює і на Android.
- Покращено процес міграції даних на іншу БД з SQLite. Головне з покращень:
- Оптимізовано швидкість перенесення даних майже в 3 рази (наприклад база даних 10гб даних переноситься орієнтовно за 40 хвилин).
- Додатково у вебінтерфейсі буде відображатись прогрес перенесення даних по конкретному пристрою та скільки пристроїв перенесено/скільки лишилось.
- Міграція тепер працює для postgresql баз даних де користувач, який використовується застосунком для підключення до БД, не має
SUPERUSERправ. - Виправлено ситуації коли після успішного завершення міграції у вебінтерфейсі нескінченно відображалось сповіщення про завершення міграції.
- Змінено механізм роботи з чеками для postgresql баз даних, де користувач який використовується застосунком для підключення до БД, не має
SUPERUSERправ щоб коректно працювала очистка чеків. Для користувачів що маютьSUPERUSERправа - все залишилось без змін. - Додано можливість проводити операції з очікуванням підтвердження/корекції для терміналів ingenico по протоколу
BPOS1. - Змінено умови перерахунку суми за одиницю товару в чеку щоб не виникало розбіжностей в ціні за одиницю після фіскалізації чеку з товарами кількість яких не кратна 1.
- Змінено формат валюти на
ГРНу json відповіді для всіх протоколів роботи з терміналами так як деякі термінали повертали або некоректне значення, або код валюти. - У відповіді на службові завдання (
task) 5, 22, 23 повертається значенняisprintаналогічно іншим заваданням, наприклад фіскалізація чеку, для перевірки чи було документ доставлено для друку. - Виправлено помилку з підключенням до MS SQL бази даних в разі якщо назва БД має спец символ або виключно числова.
- Виправлено помилку коли зберігався пошкоджений файл оновлення при розриві з'єднання у разі завантаження його із серверу.
- Зроблено низку виправлень та покращень при роботі з терміналами verifone та newland по протоколу SSI JSON, а саме:
- Покращено механізм обробки відповіді від терміналу після завершення операції що має вирішити проблеми із зависанням обробки операції і повернення помилки після таймауту, навіть якщо операція успішна.
- В разі розриву зв'язку з терміналом буде відбуватись автоматичне перепідключення до 3-х спроб щоб не втратити дані про поточну операцію.
- Виправлено помилку з помилковою фіскалізацією чеку в пакетному режимі в разі отримання помилки від процесингового центру (наприклад у разі нестачі коштів) при проведенні операції з очікуванням підтвердження/корекції на терміналах Приватбанку.
- Корегування схеми передачі кількох податків що відносяться до одного товару згідно нових вимог ДПС. Зміни стосуються лише схеми роботи коли для товарів податкові групи передаються через масив
taxgrpsзамість параметруtaxgrp. - Виправлено помилку коли знижка на весь чек не враховується до суми чеку в значенні параметру
qr1у JSON відповіді після фіскалізації чеку. - Додаткова перевірка даних на випадки коли з облікової системи в JSON запиту на фіскалізацію чеку передаються некоректні unicode escaped символи.
У випадку якщо отримано некоректні дані - буде повернуто помилку при фіскалізації:
Некоректно передано дані у вхідному JSON запиту. Перевірте коректність переданих значень та повторіть запит.
- Виправлено помилку коли при автовідкритті зміни з першим чеком, при певних умовах, не оновлювались налаштування ПРРО.
- Виправлено можливі проблеми в роботі каси при падінні серверу БД в момент оновлення інформації по чеку після його реєстрації в ДПС.
- Виправлено некоректний текст помилки при передачі заборонених символів до товарів в значення параметрів
code_aтаcode_aa. - Виправлено помилку при запуску застосунку якщо створено термінал по протоколу simpays ккм по якому відкривається TCP Server для комунікації з терміналом на зайнятому в системі порту.
- Виправлено деякі помилки що виникали при виконанні синхронізації чеків за останню зміну.
- Допрацювання для подільшої кореткної роботи функціоналу заміни ключів ЕЦП через панель адміністрування.
- Низка технічних покращень для стабільної роботи.
¶ 6.0.2 - patch від 31.01.2025
- Виправлено помилку при фіскалізації чеків з кількома податками якщо до товару не було передано значення
code.
¶ 6.0.1 - patch від 30.01.2025
-
Прибрано автозаповнення коду товару (
"code") назвою товару ("name") якщо код не було передано в запиті на фіскалізацію чеку, що призводило до дублювання відображення назви на сторінці перегляду чеку в податковій, де виводиться в один радок назва та код товару. -
Додано обов'язкове поле "Контакти" при відправці запиту про допомогу.
-
Виправлено проблему з некоректним залишком по ПРРО в разі перенесення ПРРО в інший Device Manager при увімкненому налаштуванні перенесення залишку готівки зі зміни в зміну
-
Додано можливість підключати термінали ingenico по протоколу BPOS1 від банку ПУМБ.
-
Виправлено помилки в назвах протоколів при підключенні терміналів для деяких банків.
-
Прибрано можливість "Перевірити зв'язок з банком" на сторінці налаштувань терміналу у зв'язку з особливостями роботи цієї операції на різних терміналах. Натомість додано можливість прововести операцію оплати, повернення чи скасування по терміналу.
-
Виправлено проблему з дублюванням однакових попереджень в масиві об'єктів "warnings" у відповіді після фіскалізації чеку.
-
Виправлено помилку
Сума базових сум податків не співпадає з сумою оплатяка виникала після синхронізації чеків по зміні з кабінетом Вчасно.Каса у разі відсутності певних даних в чеках. -
Виправлено помилку при першому запуску Device Manager на чистій MS SQL базі.
-
Виправлено помилку що при певних умовах не отримувались офлайн номери асинхронно під час роботи ПРРО.
¶ 6.0 - major від 16.01.2025
З даної версії було змінено сервер для завантаження оновлень з
dm-releases.c.prom.stнаkasa.vchasno.ua.
Всі версії Device Manager вище за 5.195 включно тепер будуть завантажувати файли зkasa.vchasno.ua
- Зміни у формах чеків. Накази №674 та №601 які визначають нові вимоги до формату чеків вже набули чинності.
Офіційно за старою формою фіскального чека можна працювати до 1 березня 2025 року, а вже з цього дня буде потрібно перейти на оновлену форму.
В новій версії уже готові всі зміни, які уже скоро будуть увімкнені. Допрацювань з боку облікової системи виконувати не потрібно, форми зміняться автоматично, достатньо оновити застосунок.
Якщо у вас використовується власна друкована форма чеків або ж в Device Manager завантажена користувалька друкована форма, ознайомтесь з інформацією за посиланням.
-
Додано можливість використовувати хмарні підписи Вчасно.КЕП для підписання чеків.
Як завантажити та почати користуватись деталі за посиланням. -
В разі виниклення проблем з роботою ПРРО, терміналу чи принтеру що працюють через Device Manager тепер можна передати запит про допомогу напряму із застосунку до служби турботи Вчасно.Каса, вони зможуть перевірити всю необхідну інформацію та одразу допомогти із вирішенням вашого питання.
Додатково запросити допомогу можна буде через через панель адміністрування, з можливістю відслідковувати статуси ваших звернень. -
Додано можливість проводити операції з очікуванням підтвердження/корегування з боку облікової системи для терміналів Приватбанку по JSON протоколу. Як налаштувати та проводити оплати в такому режимі.
-
Додано можливість відключити обмеження на фіскалізацію одних і тих самих товарів в чеках з різними податковими групами в рамках однієї зміни на ПРРО.
В разі фіскалізації одних і тих же товарів в чеках з різними податковими групами в одній зміні при увімкненому контролі (контроль по аналогії як на класичних РРО) ви отримаєте наступну помилку:
{
"ver": 6,
"resp_ver": 4,
"source": "",
"device": "DEV",
"tag": "067F144C-58DB-455D-86DC-288CC3896E4F",
"task_status": 3,
"type": 1,
"task": 1,
"dt": "20250115144324856",
"res": 1111,
"res_action": 3,
"errortxt": "Код товару 99426881 було продано раніше по податковій групі 1(А)",
"aq_errortxt": "",
"warnings": []
}
Для відключення в об'єкт fiscal.receipt необхідно передати параметр "disable_taxes_control": true
В такому разі дана перевірка виконуватись не буде і чек фіскалізується без помилок.
- Додано можливість автоматично закривати зміни по всім відкритим касам що працюють в поточному Device Manager при закритті зміни по одній касі.
Для виконання такого закриття необхідно в запиті на закриття зміни в об'єктfiscalпередати параметр"close_all_shifts": 1
Приклад повного запиту на закриття зміни
{
"ver": 6,
"device": "DEV",
"tag": "",
"type": 1,
"fiscal": {
"task": 11,
"close_all_shifts": 1
}
}
Якщо зміна по касі по якій було відправлено запит на закриття зміни буде закрита успішно, за кілька секунд Device Manager закриє, по черзі, всі зміни, які відкриті, по іншим касам.
Важливо врахувати що поточний функціонал не включає повернення відповіді із даними по всім Z-звітам по всім касам, будуть повернені дані лише по касі, по якій виконано запит закриття, інші ж зміни будуть закриті асинхронно.
Також в разі помилки при закритті зміни по іншим касам, якщо ПРРО не зможе, з певних причин, перейти в офлайн - повторної спроби закриття не буде.
-
Можливість передавати необхідні дані в чек для коректного формування XML звіту по програмі
єКнига. -
Зміна валідації кодів УКТ ЗЕД в чеках.
В полеcode2для кожного товару схема доступних значень для передачі наступна:
10-значний номер (наприклад, 1234567890)
8-значний номер (наприклад, 12345678)
6-значний номер (наприклад, 123456)
Номер, що починається з 00, за яким йде рівно три цифри (наприклад, 00123)
4-значний номер (наприклад, 1234)
Значення 0
Для сумісності з інтеграціями з попередніми версіями код 10 цифр та опціональний символ # з початку чи в кінці коду будуть також прийматись. Символ # буде обрізано в процесі обробки чеку для передачі в ДПС лише цифрового коду.
В разі некореткної передачі буде повернуто помилку з вказанням в якому товарі його було зазначено некоректно:
{
"ver": 6,
"resp_ver": 4,
"source": "",
"device": "DEV",
"tag": "10E3838D-91E5-45D3-90C5-F7A3E251B444",
"task_status": 3,
"type": 1,
"task": 1,
"dt": "20250115152955777",
"res": 1089,
"res_action": 3,
"errortxt": "Позиція Горілка, містить некоректно зазначений код УКТ ЗЕД (\"code2\"). Допустимі значення: 4, 6, 8, 10 цифр або 5, якщо перші дві з них це 00.",
"aq_errortxt": "",
"warnings": []
}
-
Можливість обійти розбіжність в ціні за одиницю в чеку при передачі до товару суми позиції (
"cost") одночасно з ціною за одиницю ("price"). Суть проблеми в тому що при зворотньому перерахункуcost/cntдля коректної передачі суми товару за одиницю в ДПС, із за математичного округлення, особливо у вагових товарах, перерахована ціна за одиницю могла відрізнятись від ціни (price), що була в запиті, на одну копійку. Для обходу розбіжності необіхдно до товару передавати лише ціну за одиницю (price) та кількість (cnt) і не передавати загальну суму позиції (cost). -
Виправлено помилки з можливим зависанням принтера при друку в разі проблем із доступом до бази даних.
-
Виправлено помилки коли не включена у вартість комісія не враховувалась при розрахунку виручки та суми готівки в касі у разі виконання повернень.
-
Виправлення можливого невдалого завантаження файлу для оновлення, у деяких випадках, що призводило до неможливості надалі оновлювати застосунок через кнопку у вебінтерфейсі.
-
Допрацьовано схему роботи з податками ПДФО 18% та ВЗ 5% для клієнтів що є податковми агентами. Попередні налаштування тепер виконуються спеціалістами Вчасно.Каса по запиту клієнта, більше передавати в чеки параметр
"tax_not_incl_alg": 1у об'єктfiscal.receiptне потрібно. -
Виправлено помилку з дуже коротким очікуванням відповіді від терміналу при закритті зміни на терміналі по протоколу
BPOS1. -
Виправлено проблему з розрахунком ПДВ для чеків з одним і більше товарів що обкладаються ПДВ та Акцизом одночасно при роботі зі схемою накладання кількох податкових груп на один товар (наприклад окремо ПДВ 20% та окремо Акциз 5%) замість стандартної.
¶ 5.198.3 - patch від 04.12.2024
- Виправлено помилку з фіскалізацією службового внесення/винесення та чеків видачі готівки держателям ЕПЗ.
¶ 5.198.2 - patch від 03.12.2024
- Виправлено помилку в роботі пакетного режиму при використанні терміналу.
¶ 5.198.1 - patch від 03.12.2024
- Додано можливість проводити по терміналу операцію оплати з підтвердженням. Детальніше
- Оновлено бібліотеку POSAPI для роботи з терміналами до версії 1.40.0.0
- Додано можливість підключати термінали ingenico по протоколу BPOS1 від Райффайзенбанку.
- Додано
/до списку дозволених символів при створенні ПРРО, принтерів чи терміналів. - Для пакетного режиму додано можливість через параметри запиту вказувати з яким принтером чи терміналом працювати в рамках поточного запиту ігноруючи підключені пристрої в налаштуваннях.
Для цього в параметрах до запиту потрібно передати:
trm_name- Назва терміналу створеного в Device Manager.prn_name- Назва принтеру створеного в Device Manager.
У випадку передачі цих параметрів - в рамках запиту в пакетному режимі Device Manager буде використовувати для роботи саме цей принтер та термінал. Якщо їх не передавати - використовуватимуться пристрої які вказані в налаштуваннях пакетного режиму до ПРРО.
- Виправлено помилку зі зчитуванням ключів виданих КНЕДП ДПС у певних випадках.
- Змінено порт серверу для друку чеків для терміналів Verifone X990 та Newland що працюють по протоколу SSI JSON. Наразі після оновлень з боку розробників терміналів порт для друку буде на 1 більше ніж порт платіжного застосунку.
- Виправлено помилкові спроби друку чеку при роботі в пакетному режимі якщо немає підключеного принтера.
- Виправлено помилку з можливою у деяких випадках відсутністю інформації по завантаженому ключу ЕЦП у вебінтерфейсі.
- Виправлено помилку при використанні для різних товарів одної та двох податкових груп в одному чеку при передачі податкових груп через
taxgrpsзамістьtaxgrp. - Виправлено помилку з математичним округленням 1 копійки при фіскалізації чеків з податковою групою ПДВО та ВЗ при деяких варіаціях сум у чеку.
¶ 5.198 - release від 20.11.2024
- Адмін панель для моніторингу роботи кас всієї мережі. Які доступні можливості та як налаштувати.
- Допрацьовано передачу даних до ДПС по програмі "Національний кешбек". Детальніше про зміни.
- Додано можливість при виконанні X або Z звітів отримувати список чеків по зміні. У JSON відповіді до звіту буде повернуто масив об'єктів (чеків) з наступною інформацією:
-Дата і час формування чеку в форматі DD.MM.YYYY hh.mm.ss (`"datetime"`);
-Фіскальний номер чеку (`"fisnum"`);
-Значення tag (`"tag"`);
-Тип чеку(номер завдання) (`"type"`);
-Сума чеку (`"sum"`);
-Сума податків(загалом) (`"tax_sum"`).
Для отримання списку чеків потрібно передати в запиті в об'єкті fiscal параметр “get_receipts“: true
- Можливість сформувати новий службовий звіт по чекам.
GET /dm/vchasno-kasa/api/v3/docs
Параметри для запиту:
dev_name - назва ПРРО, якщо не передано - формується звіт по всім касам.
dev_id - внутрішній id каси в ДМ, якщо не передано - формується звіт по всім касам.
pg_no - Пагінація, номер сторінки.
pg_cnt - Пагінація, кількість чеків на одній сторінці.
dt_from - Дата початку періоду чеків для фільтрації даних в форматі YYYYMMDDHHMMSS, дату можна передавати частково, наприклад YYYYMMDD
dt_to - Дата закінчення періоду чеків для фільтрації даних в форматі YYYYMMDDHHMMSS, дату можна передавати частково, наприклад YYYYMMDD
dt_order - Сортування чеків в масиві docs по даті, desc - від більшого до меншого чеку по даті, asc - від меншого до більшого.
Опис відповіді:
об'єкт paging
"page_number" - номер сторінки. Рівне тому значенню що передано в параметрах до запиту, якщо не передано - завжди 1.
"page_size" - кількість записів на сторінці. Рівне тому значенню що передано в параметрах до запиту, якщо не передано - завжди дорівнює кількості чеків що були знайдені.
"total_records" - Загальна кількість записів по поточним параметрам.
"total_pages" - Загальна кількість сторінок.
об'єкт docs
"rro_fiscal_number" - ФН каси з якої був виданий цей чек.
"fiscal_number" - фіскальний номер чеку.
"doc_type" - тип чеку цифрою, фактично номер завдання (task).
"doc_type_txt" - тип текстом, наприклад "Чек" або "Повернення" або "Переказ коштів"
"sum" - сума чеку.
"dt" - дата та час формування чеку в форматі YYYYMMDDHHMMSSMMM.
"subtask" - те значення subtask що передано в JSON запиту.
"fcId" - те значення fcId що передано в JSON запиту.
Приклад відповіді
{
"res": 0,
"errortxt": "",
"paging": {
"page_number": 1,
"page_size": 10,
"total_records": 13,
"total_pages": 2
},
"docs": [
{
"rro_fiscal_number": "99996655555555",
"fiscal_number": "TEST_d8neVgxNk6ppow",
"doc_type": 2,
"doc_type_txt": "Повернення",
"sum": 4241,
"dt": "20241029115400235",
"subtask": 1,
"fcId": "2e323r23r"
},
{
"rro_fiscal_number": "99996655555555",
"fiscal_number": "TEST_amkSmyoLiJ5Hdw",
"doc_type": 2,
"doc_type_txt": "Повернення",
"sum": 4241,
"dt": "20241029115333650",
"subtask": 1,
"fcId": ""
},
{
"rro_fiscal_number": "99996655555555",
"fiscal_number": "TEST_b4BZK3NKnePNtg",
"doc_type": 2,
"doc_type_txt": "Повернення",
"sum": 4241,
"dt": "20241029115304910",
"subtask": 0,
"fcId": ""
},
{
"rro_fiscal_number": "3",
"fiscal_number": "TEST_8_mjQ96Rn_VmrA",
"doc_type": 16,
"doc_type_txt": "Видача коштів при переказі",
"sum": 50,
"dt": "20241029114508675",
"subtask": 0,
"fcId": ""
},
{
"rro_fiscal_number": "3",
"fiscal_number": "TEST_QsOh47BjphpFMw",
"doc_type": 15,
"doc_type_txt": "Переказ коштів",
"sum": 240,
"dt": "20241029114501687",
"subtask": 0,
"fcId": ""
},
{
"rro_fiscal_number": "3",
"fiscal_number": "TEST_OFN_GM2DvO-norXXGg",
"doc_type": 1,
"doc_type_txt": "Чек",
"sum": 1000,
"dt": "20241015180857139",
"subtask": 0,
"fcId": ""
},
{
"rro_fiscal_number": "3",
"fiscal_number": "TEST_OFN_UuBMd-MR9jvP5g",
"doc_type": 1,
"doc_type_txt": "Чек",
"sum": 1000,
"dt": "20241015180150531",
"subtask": 0,
"fcId": ""
},
{
"rro_fiscal_number": "3",
"fiscal_number": "TEST_OFN_wTAMJR1MV2X2NQ",
"doc_type": 1,
"doc_type_txt": "Чек",
"sum": 1659.07,
"dt": "20241015103240346",
"subtask": 0,
"fcId": ""
},
{
"rro_fiscal_number": "3",
"fiscal_number": "TEST_OFN_5af_k-sGnwD0rw",
"doc_type": 1,
"doc_type_txt": "Чек",
"sum": 1659.07,
"dt": "20241015102946116",
"subtask": 0,
"fcId": ""
},
{
"rro_fiscal_number": "3",
"fiscal_number": "TEST_8oviAPTPXrK_Pw",
"doc_type": 1,
"doc_type_txt": "Чек",
"sum": 730,
"dt": "20241004173326313",
"subtask": 0,
"fcId": ""
}
]
}
- В реєстр чеків було додано можливість переглянути типи оплати якими був оплачений чек. Якщо в чеку було кілька видів оплат одночасно - вони будуть відображені через кому.
Для отримання такої ж інформації через API при виконанні GET /dm/vchasno-kasa/api/v1/shiftdocs потрібно в параметри запиту передати show_pay_types=true
До кожного чеку буде повернуто масив об'єктів pays із даними:
"sum" - сума по виду оплати, 2 знаки після коми
"pay_code" - код виду оплати, згідно кодів оплат.
"typen" - текстове найменування виду оплати.
-
Спрощено перехід на іншу базу даних зі стандартної sqlite та можливість в один клік перенести всі ваші дані.
Тепер щоб змінити базу даних та/або перенести дані достатньо перейти в налаштування застосунку та вказати дані для підключення. Деталі за посиланням -
Заборонено створювати назви для ПРРО принтерів або терміналів із деякими спец символами символами, які можуть викликати певні помилки в роботі.
При спробі створити або відредагувати пристрій із не дозволеними символами, буде повернуто помилку (наприклад):У назві присутні заборонені символи: "№, %".
В разі якщо у назві буде вказано знак табуляції, нерозривний пробіл або символ пробілу з початку або з кінця назви вони будуть автоматично обрізані без повернення помилки перед збереженням назви.
Дозволені символи:
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz АБВГДЕЁЖЗИЙКЛМНОПРСТУФХЦЧШЩЪЫЬЭЮЯабвгдеёжзийклмнопрстуфхцчшщъыьэюя
ІіЇїҐґЄє
!.,";:?()_«»-0123456789
- Автовизначення АЦСК при зчитуванні ключа ЕЦП. При додаванні ключа ЕЦП до ПРРО в полі "АЦСК" тепер не обов'яково вказувати найменування вашого АЦСК, можна залишити пункт "Визначити автоматично".
Якщо доступ до АЦСК наявний з вашого пристрою, АЦСК буде визначено автоматично і завантажено ключ.
Наразі даний функціонал не працює для android
- Можливість встановлювати власний таймаут очікування відповіді від терміналу. Так як деякі термінали можуть проводити оплату більше як 2хв. із за чого виникають розбіжності в даних по ПРРО і по терміналу наразі можна встановити власне значення скільки очікувати відповідь від терміналу.
В налаштуваннях кожного терміналу у пункті "Додаткові налаштування терміналу" можна вказати час (в секундах) скільки застосунок буде очікувати відповідь від терміналу.
Враховуйте що на доданий час потрібно буде збільшити час очікування відповіді в обліковій системі.
-
В пакетному режимі (запит на
/dm/execute-pkg) дозволено виконувати відкриття зміни та інші завдання по ПРРО.
Загалом повний перелік дозволених завдань (task): 0, 1, 2, 3, 4, 5, 10, 11, 12, 13, 14, 15, 16, 18, 20, 21, 22, 23 -
Додано автовиправлення некоректного JSON відповіді від терміналів Приватбанку. В разі якщо було отримано некоректний JSON - буде виконано його автоматичне корегування, якщо JSON кореговано успішно - термінал зможе далі працювати, в разі неможливості скорегувати JSON операцію оплати буде скасовано. В такому разі рекомендуємо звернутись до Приватбанку для доналаштування терміналу.
-
Змінено схему обробки відповіді від терміналів Приватбанку на випадки якщо термінал повертав що операція пройшла успішно - проте насправді була помилка. Тепер такі операції не будуть визначатись застосунком як помилково успішні.
-
Можливість налаштувати автоскасування успішної оплати чи повернення по терміналу в разі якщо облікова система не дочекалась відповіді від Device Manager або "відпала" з певних причин.
З нової версії застосунок може чітко визначати на момент повернення відповіді на API запит оплати ("task": 1) чи повернення ("task": 2) по терміналу чи доступний ініціатор запиту (облікова система).
В разі якщо потрібно щоб застосунок скасовував успішну оплату чи повернення якщо облікова система недоступна - потрібно передавати в запиті в об'єкті"pay"параметр"cancel_on_disconnect": true
Приклад запиту
{
"ver": 6,
"source": "DM_API",
"device": "Term",
"type": 3,
"pay": {
"cancel_on_disconnect": true,
"task": 1,
"merch": "1",
"sum": 11
}
}
В такому разі якщо застосунок не зможе повернути відповідь - він скасує оплату автоматично.
- Додано можливість змінювати таймзону яку буде використовувати застосунок при визначені системного часу.
Якщо у вашій системі часовий пояс не відповідає київському часу, та немає можливості його змінити в системі - у вас можуть виникати помилки при фіскалізації чеків так як час чеків контролюється на коректність та відповідність.
Для примусового переналаштування часового поясу який буде використовувати застосунок потрібно в конфігураційний файл EDMSrv.ini додати параметри в секцію [Server]
UseTimeZone - використовувати форсовану таймзону. 1 - так, 0 або не заповнено - ні.
TimeZone - значення таймзони в форматі: 2, -2 і тд. Потрібно поставити саме значення 2.
Приклад:
Після збереження налаштувань те перезапуску застосунку для чеків буде використовуватись нова таймзона.
-
Допрацьовано автооновлення для можливості його роботи на різних дистрибутивах linux.
-
Додано можливість по аналогії з деякими "Класичними РРО" накладати кілька податків на один товар (наприклад окремо ПДВ 20% та окремо Акциз 5%). Відповідно при такій схемі роботи обіг по групі, в даному прикладі, ПДВ 20% при використанні ПДВ 20% для одного товару та ПДВ 20% + Акциз 5% буде спільний.
Для роботи даного способу передачі податків в чеку потрібне попреднє налаштування податкових груп, для цього зверніться на техпідтримку.
Для цього в чеку потрібно до кожного товару замість "taxgrp" в масиві об'єктів fiscal.receipt.rows передавати масив "taxgrps" куди вказати одну або дві податкові групи якими обкладається товар.
Приклади запитів
Чек товар ПДВ 20% + Акциз 5%:
{
"ver": 6,
"source": "API",
"device": "postgres1",
"tag": "",
"need_pf_img": 1,
"type": 1,
"fiscal": {
"task": 1,
"receipt": {
"sum": 100,
"rows": [
{
"code": "10",
"name": "Товар з акцизом",
"cnt": 1,
"disc": 0,
"price": 100,
"cost": 100,
"taxgrps": [
1, 4
]
}
],
"pays": [
{
"type": 0,
"sum": 100
}
]
}
}
}
Приклад чеку:
Чек товар ПДВ 20%
{
"ver": 6,
"source": "API",
"device": "postgres1",
"tag": "",
"need_pf_img": 2,
"type": 1,
"fiscal": {
"task": 1,
"receipt": {
"sum": 100,
"rows": [
{
"code": "11",
"name": "Товар",
"cnt": 1,
"disc": 0,
"price": 100,
"cost": 100,
"taxgrps": [
1
]
}
],
"pays": [
{
"type": 0,
"sum": 100
}
]
}
}
}
Приклад чеку:
Приклад звіту:
-
Додано попередження при створенні ПРРО при роботі застосунку на базі даних SQLite якщо кількість більше 7 що максимально можливо використовувати до 10 ПРРО.
-
Реалізовано можливість використовувати накладений податок замість вкладеного при роботі з товарами. Під накладеним податком мається на увазі можливість передавати суму товару без податку - відповідно податок буде розраховуватись і накладатись поверх суми. Сума до сплати в такому разі буде більше за суму чеку на суму податку.
Для роботи даного способу розрахунку податків в чеку потрібне попреднє налаштування податкових груп, для цього зверніться на техпідтримку.
- Відкориговано схему обрахунку ПДФО 18% та ВЗ 1.5% та додано можливість передавати суму послуги виплати виграшу з податком або без податку при використанні даної податової групи. Залежно від схеми податок буде пораховано від суми або накладений поверх суми послуги.
Для роботи даного способу розрахунку податків в чеку потрібне попреднє налаштування податкових груп, для цього зверніться на техпідтримку.
-
Виправлено помилку коли найменування АЦСК у списку дублюються в разі повторного завантаження ключа на сторінці ПРРО.
-
Змінено основний колір інтерфейсу
-
Виправлено проблему коли завантажувався пошкоджений файл логу на linux за поточний день.
-
Виправлено проблему з блокуванням/розблокуванням ПРРО через "Інженерні функції" вручну яке могло призвести до зависання застосунку у певних випадках.
-
Виправлено можливі проблеми в роботі каси в разі якщо у фоні запитуються офлайн номери і в цей момент відбувається фіскалізація чеку.
-
Збільшено кількість максимально можливої довжини для назви товару в чеку з 200 до 1000 символів.
-
Виправлено помилку з некоректним автоматичним розрахунком ціни за одиницю в чеку (
"price") якщо передано лише повну вартість позиції ("cost"). -
Виправлено помилку коли заборона переходити в офлайн після аварійної заміни ключа не працювала при певних умовах.
-
Виправлено помилку в роботі ПРРО після автоматичної синхронізації чеків у певних випадках.
-
Виправлено помилку коли загальна знижка на весь чек переходить в націнку у візуалізації чеку для останнього товару в списку якщо сума знижки більше за суму останнього товару.
-
Відкориговано схему нарахування загальних знижок на весь чек по товарам враховуючи індивідуальні знижки на товари в чеку.
-
Відкориговано розподілення знижки по товарам виключаючи товари з додатковим збором (при передачі в запиті в об'єкт
fiscal.receiptпараметру"disc_calc_alg": 1) -
Виправлено помилку при отриманні відповіді від терміналу newland по протоколу SSI JSON.
-
Виправлено помилку з екрануванням апострофа в деяких варіаціях назв товарів в чеку.
-
Виправлено проблему з роботою деяких налаштувань в застосунку після запуску застосунку якщо на момент запуску були проблеми з підключенням до серверу бази даних.
-
Виправлено текст помилки про те що автооновлення не підтримується на android.
¶ Попередні версії
5.197.4 - patch від 17.09.2024
- Виправлено помилку з розрахунком 100% знижки на весь чек при певних варіаціях сум вказаних в товарах що призводило до помилки при фіскалізацію чеку.
- Виправлено помилку
Access violation...у випадку фіскалізації чеку з великою кількістю товарів (20-30+) на x32 версії застосунку. - Виправлено помилку з некоректним форматуванням часу на чеку в певних випадках при переході в офлайн.
- Виправлено помилку з фіскалізацією чеку в пакетному режимі одразу після оновлення на нову версію застосунку якщо зміна по ПРРО була відкрита.
- Відключено перевірку розмірності полів
"purchase_receipt_fisn"та"purchase_rro_fisn"для чеків повернення.
5.197.3 - patch від 11.09.2024
- Виправлення розрахунку "Виручки" у звітах при наявності чеків з товарами/послугами з накладеним податком
ПДФО 18% + ВЗ 1.5%. - Виправлено присвоєння помилкової дати чеку при переході в офлайн на фіскалізації чеку з автовідкриттям зміни.
- Виправлено значення суми залишку готівки в касі в разі якщо посеред відкритої зміни по касі була запущена зворотна синхронізація чеків при перенесенні ПРРО з одного пристрою на інший.
- Виправлено проблему з некоретними розрахунками по знижці в чеку якщо сума знижки 0 та цю знижку передано за допомогою масиву знижок
"discounts". - За замовчуванням змінено спосіб друку зображення в режимі "Для розфіскалізованих РРО" для більшої швидкості друку чеків.
- Виправлено помилку з аварійним завершенням роботи застосунку в разі зчитування ключа ЕЦП при певних умовах.
- Виправлено помилку при спробі надрукувати чек за допомогою терміналу якщо в налаштуваннях терміналу вказано порт відмінний від стандартного. (для терміналів що працюють по SSI JSON протоколу).
- Виправлено помилку збереження частини чеків в разі перебоїв роботи мережі при синхронізації чеків за останню зміню по ПРРО.
5.197.2 - patch від 04.09.2024
- Виправлено деякі механізми в роботі застосунку які могли призводити до помилок в роботі або поломки БД SQLite в разі доступу до бази одночасно з різних процесів.
- Вимкнено перевірку наявності в оплатах готівки при використанні округлення якщо загальна сума чеку дорівнює нулю, для коректної фіскалізації чеків повністю оплачених бонусами.
5.197.1 - patch від 03.09.2024
- Виправлено помилки з перевірками даних в JSON запиті по чеку при роботі в пакетному режимі з увімкненим налаштуванням автовідкриття зміни з першим проведеним чеком.
- Для всіх банків та протоколів роботи з терміналами змінено схему отримання ідентифікатора еквайера (мерчанту) для коректної відправки даних до ДПС по програмі "Національного кешбеку".
Тепер в поле ідентифікатор мерчанту (bank_id) буде поміщатись внутрішній номер мерчанту який присвоюється банком. Додано нове поле Назва банку (bank_name), для відображення в чеку найменування банку до якого належить платіжний засіб. Дані про банк не будуть передаватись в ДПС.
В разі роботи з ПРРО через пакетний режим або при роботі з терміналами через Device manager ці дані будуть отримуватись з терміналу та заповнюватись автоматично. - Додано можливість для чеків повернення передавати фіскальний номер чеку на продаж та фіскальний номер РРО/ПРРО з якого було раніше проведено чек продажу для коректної відправки даних до ДПС по програмі "Національного кешбеку"
5.197 - release від 29.08.2024
- Додано новий банк "Monobank" для роботи з терміналами Verifone по протоколу SSI JSON.
- Додано новий банк "Укрексімбанк" для роботи з терміналами Verifone та Newland по протоколу SSI JSON.
- Оновлення Device Manager під android. Також для роботи під android додано нові банки та термінали.
- Додано можливість контролювати нарахування загальної знижки на товари податкові групи яких включають додатковий збір.
Наприклад для груп:
- ПДВ 20% + акциз 5%
- Без ПДВ + акциз 5%
Для того щоб загальна знижка на весь чек не розбивалась на товари з додатковим збором(в прикладі з акцизом) потрібно передати в JSON body запиту в об'єктfiscal.receiptпараметр"disc_calc_alg": 1.
Якщо передано"disc_calc_alg": 1в такому разі у випадку наявності в чеку товарів (по прикладу вище) з податковими групамиПДВ 20% + акциз 5%абоБез ПДВ + акциз 5%на них загальна знижка на весь чек застосовуватись на буде. Деталі по роботі зі знижками за посиланням.
- Виправлено помилку
Access violation...при одночасній роботі з кількома терміналами Приватбанку. - Розширено запис логів роботи з терміналом для терміналів що використовують протоколи BPOS1 та PrivatBankJSON.
- Змінено процес синхронізації дати оплати по касі з кабінетом Вчасно.Каса для відображення завжди актуальної дати до якої ПРРО оплачено.
- Додано можливість зчитувати ключі-печатки 2в1 від Приватбанку. Після завантаження ключа Приватбанку буде відображено перелік доступних ключів, потрібно обрати один із доступних який саме потрібно завантажити до ПРРО. Для звичайних ключів Приватбанку значення ключа буде автозаповнено.
- Автоматичне скасування проведеної операції по терміалам Приватбанку в разі отримання від терміналу некоректної відповіді. Для виправлення рекомендовано звернутись до Приватбанку.
- Додано можливість сформувати короткий періодичний звіт без додаткової інформації по кожному звіту у вибірці. Для цього в JSON body запиту на формування періодичного звіту ("task" 12 та 13) потрібно передавати в об'єкті
fiscalпараметр"is_short": true. В такому разі буде сформовано короткий звіт.
Приклад запиту:
{
"fiscal": {
"dt_to": "20240805235959",
"dt_from": "20240801000000",
"is_short": true,
"task": 13
},
"type": 1,
"source": "API",
"device": "postgres1",
"ver": 6
}
- Відображення коду ЄДРПОУ або податкового номеру у всіх звітах та службових документах у рядку 4 аналогічно до фіскальних чеків.
- Виправлено помилку із завантаженням сторінки налаштування пристроїв при використання деяких спец символів або кирилиці в назві принтеру або терміналу.
- Додано перевірку статусу каси в ДПС в разі отримання певних помилок при фіскалізації чеків. Якщо від податкової буде отримано що статус каси "Скасована в ДПС" фіскалізовувати чеки та переходити в офлайн по ПРРО буде заборонено.
- Додано контроль наявності готівки в оплатах при використанні округлення. Якщо передано будь який безготівковий вид оплати та округлення більше або менше 0 - буде повернуто помилку.
- Виправлено розрахунок вартості послуг(
price*cnt) якщо не передано їх фінальну вартість(cost) для чеків переказу коштів та видачі коштів при переказі. - Допрацьовано схему роботи з наявною комісією в оплатах по чеку що не включена у вартість товару.
- Виправлено помилку з некореткною датою для чеків в разі збою часу на пристрої та переходу ПРРО в офлайн до відкриття зміни по ПРРО.
- Виправлено помилку при спробі відкрити зміну по касі по якій раніше не було змін проте були проведені службові чеки.
- Виправлено помилку при спробі видалити ПРРО по якому збережено неактуальний токен в налаштуваннях. 20) Додано сортування відображення податкових груп в чеках та звітах по букві податку в алфавітному порядку.
- Виправлено помилку "Неможливо вирішити колізію. Потрібне ручне втручання" в разі якщо ПРРО не було переведено автоматично в режим офлайн наприклад через несплату тарифу.
- Додано можливість при використанні текстового режиму друку на принтері друкувати коди (QR або ШК) картинкою. Також додано автоматичне налаштування принтера при використанні режиму друку зображень "Для розфіскалізованих РРО"
- Додано можливість форматувати відображення тексту в масиві об'єктів
linesдля чеків на продаж("task": 1), повернення("task": 2) та для службового звіту("task": 5).
Для текстових даних можна додатково передавати наступні дані
"fh": 1, -- висота тексту 1 або 2, значення 2 несумісне якщо fw 1, буде друкуватись як при fw 2. Вcі інші варіації - сумісні
"fw": 1, -- ширина тексту 1 або 2.
"align": 1, - вирівнювання. 1 зліва, 2 по центру, 3 з правого боку.
"by_word": 1, - перенесення по словам, а не по буквам якщо слово не вміщається в рядок. 1- переносити по словам, 0 або не передано - переносити по буквам.
5.196.7 - patch від 17.07.2024
-
Встановлено максимальний ліміт офлайн номерів в 5000 на один ПРРО. Стандартна кількість залишилась без змін (2000 номерів). При спробі встановити більше як 5000 номерів на один ПРРО в налаштуваннях - більше 5000 отримуватись не буде відповідно до нещодавно встановлених обмежень в API ДПС.
-
Додано можливість при увімкненій авторизації у вебінтерфейсі встановити API ключ(X-Api-Key) для авторизації запитів з облікових систем по сталому ключу замість потреби авторизуватись по логіну та паролю та зберігати авторизаційну куку.
Формат API ключа - довільний. У разі встановлення в header до запитів що містять в ендпоінті /api/v1/, /api/v2/, /api/v3/ які підпадають під авторизацію потрібно передавати значення x-api-key.
Приклад
curl --location 'http://localhost:3939/dm/vchasno-kasa/api/v1/dashboard' \
--header 'x-api-key: befddabf-0adc-4767-b7fe-5078fbcbc557'
Якщо значення ключа передано коректно - потреби в авторизації не буде, буде повернуто результат виконання запиту і відповідно всі дані.
Якщо ключ передано некоректно - буде переадресація на сторінку логіну якщо не було виконано вхід та не було передано авторизаційну куку.
Для доступу до вебінтерфейсу як і раніше використовується лише логін та пароль.
- Можливість не передавати номер мерчанту(торговця) для терміналів по протоколу POSAPI. В такому разі якщо на терміналі один мерчант - термінал зможе проводити оплату. У разі якщо їх кілька на екрані терміналу потрібно буде обрати мерчанта по якому здійснити оплату.
5.196.6 - patch від 10.07.2024
- Виправлено помилку з "падінням" сервісу Device Manager у разі проблем із мережею на пристрої. У випадках якщо співпадуть внутрішні процеси оновлення сертифікатів зі запитом на ПРРО після запуску Device Manager - застосунок буде працювати штатно та ПРРО перейде в офлайн режим до відновлення мережі на пристрої.
- Виправлено помилку при спробі фіскалізації чеків після синхронізації чеків, якщо по ПРРО останній чек має меншу дату ніж чеки перед ним.
- Виправлено помилку з можливим, у деяких випадках, некоректним математичним округленням до 2-х знаків після коми при фіскалізації чеків в момент розрахунку податків у разі роботи застосунку на ОС Linux.
5.196.5 - patch від 04.07.2024
- Виправлено помилку
Internal error: Access violation at address...яка періодично виникала при оплаті на терміналах приватбанку. - Змінено схему обробки відповіді від терміналу по протоколу BPOS1 в разі якщо термінал довго опрацьовував операцію і було відправлено запит на її скасування.
- Змінено таймаут на очікування відповіді на підтвердження операції від терміналу з рекомендованих ingenico 7-ми секунд до 60 секунд для більшої стабільності роботи.
5.196.4 - patch від 01.07.2024
- Виправлено посилання для успішного оновлення сертифікатів у разі якшо з пристрою немає доступу до iit.com.ua.
- Виправлено помилку з передачею в чеку некоректного розділювача для десяткових значень відсоткової знижки у чеку.
- Виправлено некоректну поведінку при помилці опрацювання операції терміналом що призводило до помилково успішної відповіді про оплату для терміналів що працюють по протоколу BPOS1.
- Створено обробку різних форматів відповіді від терміналу при вирішенні проблем з втратою зв'язку з пристроєм в момент проведення оплати для терміналів Приватбанку. У разі помилки отримання відповіді від терміналу, повторний запит для перевірки статусу операції тепер буде повертати коректні дані не залежно від моделі терміналу на якій встановлено JSON протокол Приватбанку.
- Виконано оновлення бібліотеки підписання IIT до актуальної версії на windows/linux для вирішення проблем з падінням сервісу додатку в разі недоступносі мережевого обладання при запуску пристрою.
- Виправлено помилку при друку чеку з реєстру якщо пристроїв в ДМ > 1
- Виправлено помилку з можливим падінням служби ДМ в разі відсутності кореневого сертифікату та неможливості його завантажити із за мережевих проблем на пристрої.
5.196.3 - patch від 11.06.2024
-
Виправлено помилку в роботі ПРРО після завершення зворотної синхронізації якщо в налаштуваннях ПРРО увімкнено "Автоматичне відкриття зміни з проведенням першого чеку".
-
Виправлено помилку в роботі ПРРО після завершення зворотної синхронізації якщо по ПРРО до цього тривалий час не формувалось фіскальних чеків.
-
При налаштуванні принтеру "Відступ зліва (в міліметрах)" 0 тепер не відправляється на принтер команда для обнулення відступів.
-
Виправлено помилку з виходом ПРРО з офлайну після завершення зворотної синхронізації якщо ПРРО знаходилось в режимі офлайн.
-
Виправлено помилку з неможливістю авторизуватись у вебінтерфейс при увімкненій авторизації на більшості браузерів.
5.196.2 - patch від 07.06.2024
- Додано відображення суми комісії по оплатах у всіх звітах по чекам на повернення якщо комісія не включена у вартість товару та > 0. Сума комісії повертається у відповідь на виконання звітів в значенні:
info.pays.commission_m. - Виправлено помилку коли у разі нестабільного з'єднання з інтернетом автоматично не запускалась служба device manаger.
- Виправлено можливі помилки в роботі ПРРО після виконання зворотної синхронізації або при перестворенні ПРРО на новому пристрої.
- Виправлено помилки друку чеків на принтері якщо в налаштуваннях принтеру завантажено логотип зверху або знизу.
- Виправлено помилки із підключенням до БД MS SQL та Postgresql у разі проблем із запуском бібліотеки підписання IIT.
- Додано автоматичну переіндексацію бази даних SQLite при запуску Device Manager та об 03:00 для уникнення проблем із "випадінням" записів із індексів при раптових виключеннях ПК і подальшої розбіжності в даних при фіскалізації чеків та формуванні звітів.
- Кілька інфраструктурних виправленнь для більшої стабільності роботи за будь яких умов.
5.196.1 - patch від 31.05.2024
- Виправлено помилку із неможливістю вирішення колізії після виконання автоматичної синхронізації чеків у разі виявлення розбіжності по чекам в Device Manager та в кабінеті Вчасно.Каса.
- В інтерфейсі додано можливість сформувати чек на повернення однією кнопкою на основі чеку продажу в реєстрі документів за зміну у випадку помилкової фіскалізації чеку продажу.
5.196 - release від 29.05.2024
- Додали обробку колізійних ситуацій коли зв'язок з терміналом втрачається для терміналів Приватбанку (JSON протокол) та терміналів що використовують протокол SSI JSON для уникнення подальших розбіжностей. У таких випадка у відповідь якщо операція на терміналі не пройшла буде повернуто помилку з кодом 5000 (
"res": 5000). Якщо пройшла - дані по операції.
{
"res": 5000,
"res_action": 1,
"errortxt": "Помилка терміналу: транзакція не була проведена. Повторіть спробу ще раз."
}
- Можливість повторно отримати інформацію про виконану раніше операцію з самого терміналу на терміналах Приватбанку (JSON протокол) та терміналах що використовують протокол SSI JSON.
Для цього використовується 17 завдання ("task":17). В об'єкт"pay"необхідно:
- Privatbank JSON: передати додатково номер операції на терміналі в межах поточного дня(
"cancelid"). Якщо не передавати буде повернуто стасус та інформацію останньої успішної операції по терміналу.
Приклад запиту:
curl --location 'http://localhost:3939/dm/execute' \
--header 'Content-Type: application/json' \
--data '{
"ver": 6,
"source": "API",
"device": "Terminal",
"tag": "",
"type": 3,
"pay": {
"task": 17,
"cancelid": "469109"
}
}'
- SSI JSON: додатково нічого не потрібно. Можна отримати лише статус останньої операції на терміналі(успішна або ні)
curl --location 'http://localhost:3939/dm/execute' \
--header 'Content-Type: application/json' \
--data '{
"ver": 6,
"source": "API",
"device": "Terminal",
"tag": "",
"type": 3,
"pay": {
"task": 17
}
}'
-
Логи тепер додатково зберігаються 30 днів(за замовчуванням) в архівованому вигляді для економії місця на диску.
Якщо виставлено збереження логів 7 днів та збереження архівом - логи будуть зберігатись 37 днів загалом.
За потреби налаштування можна змінити:
-
Повертаємо коректний текст помилки в разі неможливості провести зворотну синхронізацію якщо по ПРРО відсутні зміни або по ПРРО збережено некоректний токен
-
Додали перевірку стану сертифікату ключа ЕЦП на валідність. Якщо при зчитуванні ключа чи при підписанні чеку буде отримано помилку про недійсниість сертифікату - буде додатково виконано окрему перевірку стану сертифікату. Якщо сертифікат ключа було відкликано в АЦСК - робота каси, та можливість переходу в офлайн буде заборонена до завантаження актуального робочого ключа ЕЦП.
Помилка буде наступна при спробі фіскалізувати чек або відкрити/закрити зміну:
{
"res": 1094,
"res_action": 1,
"errortxt": "Приватний ключ ЕЦП не завантажено: Сертифікат ключа ЕЦП було відкликано. Фіскалізація чеків та перехід в офлайн режим заборонено. Для продовження роботи завантажте дійсний ключ та виконайте закриття зміни якщо зміна відкрита."
}
-
Заборонено послідовну реєстрацію і видалення кількох чеків для уникнення помилок в роботі ПРРО із за некоректної відповіді з боку API ДПС. Видаляти чек можна лише один раз після видалення - наступний чек видалити буде можливо тільки якщо останній чек - було фіскалізовано в ДПС.
-
Додано метод для відправки сповіщень про чеки (відправка чеку клієнту). Метод аналогічний такому ж для відправки чеків через кабінет Вчасно.Каса напряму і насамперед розроблений для зручності в інтеграції щоб не потрібно було відправляти чеки окремо через кабінет Вчасно.Каса.
В параметр запитуdev_nameпотрібно передати назву ПРРО по якому здійснюється відправка.
Дані для відправки можна передати параметрами до запиту або в body запиту в json форматі
"recipient"- Електронна пошта або номер телефону для надсилання чеку."channel"- Канал для надсилання чеку
●email- віпправити на електронну пошту
●sms- відправити через SMS
●viber- відправити через Viber
●cascade- спробувати відправити через Viber, якщо вайбер не встановлений на телефоні, то відправити через SMS.
"check"- Фіскальний номер чеку.
Приклад передачі даний через body запиту в json форматі:
curl --location 'http://localhost:3939/vchasno-kasa/notifications/checks?dev_name=postgres1' \
--header 'Content-Type: application/json' \
--data-raw '{
"recipient": "[email protected]",
"channel": "email",
"check": "TEST_ngrGDS9vOC10cw"
}'
Приклад передачі даний через параметри запиту:
curl --location 'http://localhost:3939/vchasno-kasa/notifications/checks?dev_name=postgres1&recipient=test%40vchasno.ua&channel=email&check=TEST_ngrGDS9vOC10cw' \
--header 'Content-Type: application/json' \
--data '{}'
-
Виправлено помилку що призводила до зависання ПРРО якщо при запитів на ПРРО розірвалось з'єднання з сервером БД.
-
У візуалізації звітів(X, Z та періодичні звіти) прибрано відображення розділів по внесенням/винесенням, чекам видачі готівки держателям ЕПЗ, та чекам переказу коштів та видачі коштів при переказі якщо в зміні даних операцій не було проведено.
-
У візуалізації тестових чеків більш явно відображаємо додатково напис "Тестовий чек" зверху та знизу чеку для більшого розуміння по якому ПРРО було фіскалізовано чек.
-
Додали можливість встановлювати відступ зліва на принтерах по ESC/POS протоколу. В налаштуваннях принтеру в міліметрах можна вказати decimal значення віступу якщо чек друкується зі зміщенням а не по центру паперу.
-
Виправлено помилку з відображенням часу роботи в офлайні за поточний та попередній місяць замість тільки часу роботи в поточному.
-
Виправлено помилку з відображенням неповної інформації по ключу ЕЦП на linux.
-
Виправлено помилку з некоректним сортуванням звітів при виконанні періодичного звіту по датам якщо вказувати в запиті повну дату з мілісекундами.
-
Додано автоматичну синхронізацію даних по чекам з кабінетом Вчасно.Каса у випадку якщо є розбіжність по чекам в Device Manager та в кабінеті Вчасно.Каса і відповідно в ДПС.
Після запуску Device Manager або при відкритті зміни якщо ПРРО працює в режимі онлайн буде виконано автоматичну перевірку на відповідність, якщо буде знайдено відсутні чеки - буде виконано їх дозапис. Це допоможе відновити роботу ПРРО без додаткового налаштування якщо було аварійно закрито зміну або чеки формувались не з deivce manager. -
Змінено схему роботи функціоналу зворотної синхронізації. Якщо запущено синхронізацію без видалення чеків - буде синхронізовано дані по останній зміні ПРРО для продовження роботи. Рекомендовано використовувати у випадку якщо потрібно лише синхронізувати дані останньої зміни зі збережнням історії чеків
При синхронізації з видаленням чеків перед синхронізацією буде видалено всі чеки що є в базі даних по касі і завантажено останню зміну по ПРРО. Рекомендовано використовувати якщо ПРРО працювало на іншому пристрої або якийсь час не працювало в цьому Device Manager. -
Виправлено помилку з відображенням кількості чеків сформованих в офлайні однією загальною нумерацією для всіх ПРРО.
-
Виправлено помилку з подальшою неможливістю автоматичного виходу каси з офлайн режиму, роботою автоматичного закриття зміни та фонового отримання офлайн номерів якщо було розірвано підключення з БД(MS SQL та postgresql).
-
Виправлено помилки що призвели до довготривалого знаходження ПРРО в офлайн режимі із за проблем з ключами АЦСК Україна.
-
Додано завдання 5(
"task": 5) Універсальний сервіс(ServiceGeneric) для терміналів Приватбанку на протоколі JSON. Метод можна використовувати для провдення сервісних операцій, наприклад Оплата частинами або Миттєва розстрочка. Метод обов'язково потрібно використовувати при проведенні даних сервісних операцій якщо в терміналі кількість мерчантів(фактичних торгівців) > 1.
"task"- номер завдання - завджи 5.
"sum"- сума операції.
"param"- для оплати частинами, або миттєвої розстрочки - кількість платежів.
"merch"- номер мерчанта по якому необхідно провести операцію.
"srvNum"- номер сервісу
Номери сервісів ("srvNum") станом на 29.05.2024. Потрітно передавати значення в полі Service ID. Які саме сервіси у вас налаштовані на терміналі можна уточнити у Приватбанку.
Приклад запиту миттєвої розстрочки:
curl --location 'http://localhost:3939/dm/execute' \
--header 'Content-Type: application/json' \
--data '{
"ver": 6,
"source": "DM_API",
"device": "PAX2",
"type": 3,
"pay": {
"task": 5,
"sum": 300,
"param": 3,
"merch": 4,
"srvNum": "046"
}
}'
- Додано відображення в чеках назви та букви податку після суми чеку, які були використані якщо сума податку по цим групам рівна нулю.
5.195.6 - patch від 20.05.2024
- Повернуто стару схему роботи з архівами сертифікатів ключів ЕЦП у зв'язку з некоректною роботою бібліотеки підписання з сертифікатами.
- Додано автоматичну очистку сертифікатів ключів ЕЦП при старті Device Manager та в 03:00(для серверів) якщо змінився файл кореневого сертифікату у зв'язку з некоректною подальшою роботою бібліотеки підписання в разі невидалення сертифікатів, також відбувається автоматичне перезавантаження ключа ЕЦП до кожного ПРРО.
5.195.5 - patch від 15.05.2024
- Додаоно одноразову очистку сертифікатів ключів ЕЦП для вирішення проблеми роботи ПРРО де використовуються для підписання чеків ключі
КНЕДП ТОВ \"Центр сертифікації ключів \"Україна\"та зміна схеми роботи з сертифікатами для більшої стабільності роботи ключів надалі. - Виправлено помилку з роботою "Зворотної синхронізації".
5.195.4 - patch від 29.04.2024
- Виправлено помилку при спробі отримати список чеків по зміні по id зміни при роботі на SQLite.
- Заборонено створювати більше 10-ти касі при роботі на SQLite. Для того щоб була можливість створювати більшу кількість ПРРО в Device Manager необіхдно змінити базу даних для роботи на MS SQL або Postgresql.
- Додано додаткову звірку часу пристрою з часом на сервері Вчасно.Каса при відкритті зміни або при запуску додатку якщо зміна уже була відкрита. Допустима різниця в часі -10хв. від часу на сервері, інакше фіскалізація чеків буде заборонена до виправлення проблеми з часом на пристрої.
5.195.3 - patch від 25.04.2024
1) Додано можливість підключати термінали під управлінням протоколу SSI JSON. Доступні термінали: - термінали Newland серії SP, - термінали unattended для систем самообслуговання Newland U1000, - Android термінали Verifone X990 всіх формфакторів, - а також Андроїд терміналами інших виробників, з програмним забезпеченням SSI та протоколом SSI JSON на них.Банки еквайри платіжні застосунки яких можуть бути налаштовані на перерахованих терміналах станом на 01.05.2024:
- Ощадбанк
- Райффайзен банк
- ПУМБ
- А-банк
- Monobank
- Таскомбанк
- КІБ
- Восток Банк
- Південний Банк
- МТБ
Додатково, протягом місяця виробником терміналів буде встановлена оновлена версія платіжних додатків банків Райффайзен банк Аваль, ПУМБ, Monobank, Таскомбанк, АБанк, Укрексімбанк з підтримкою інтеграційного протоколу SSI JSON. Частина з них з них вже підтримує і відповідно доступна для підключення та роботи в Device Manager.
Всі термінали що використовують протокол SSI JSON можуть працювати в режимі 2в1, тобто термінал замінює і принтер фіскальних чеків (не тільки олачених карткою, але і готівкою також) і сам банківський термінал про проведення безготівкових розрахунків. Додатково налаштовувати принтер не потрібно, після підключення терміналу можна одразу друкувати чеки та приймати оплати.
- Додали обробку колізійних ситуацій коли термінал не отримує підтвердження отримання даних від ДМ для терміналів на протоколі BPOS1 (Ощадбанк, Укрсиббанк, Банк Південний, Банк Восток, Sense банк, А-Банк) для уникнення подальших розбіжностей. У таких випадка у відповідь якщо операцій на терміналі не пройшла буде повернуто помилку з кодом 7000 (
"res": 7000). - Можливість повторно отримати інформацію про виконану раніше операцію на терміналі по протоколу BPOS1 (Ощадбанк, Укрсиббанк, Банк Південний, Банк Восток, Sense банк, А-Банк).
Для цього використовується 17 завдання ("task":17). В об'єкт"pay"необхідно передати додатково номер мерчанту та номер операції на терміналі("cancelid").
Приклад запиту:
curl --location 'http://localhost:3939/dm/execute' \
--header 'Content-Type: application/json' \
--data '{
"ver": 6,
"source": "API",
"device": "Terminal",
"tag": "",
"type": 3,
"pay": {
"task": 17,
"cancelid": "27",
"merch": 1
}
}'
-
Додано можливість підключити термінал іншого банку якщо немає в списку доступних якщо відомий протокол роботи терміналу. Додатково потрібно буде вказати назву банку.
-
Виправлено деякі розбіжності в даних в json відповіді при фіскалізації чеків через
/dm/executeта фіскалізації аналогічного чеку через/dm/execute-prn,/dm/execute-pkg -
Можливість запису версії бази даних в конфігураційний файл. Потрібно для коректної роботи додатку з postgresql базоб даних, без можливості надати користувачу який підключається до БД
superadminправа.
в файл EDMSrv.ini в блок[Database]додати наступні рядки:
DBVerInINI=1
DBVer=
Після чого перезавантажити службу EDMSrv(windows), edm(Linux).
- Виправлено проблему з можливим зависанням сервісу в процесі запису логів роботи.
- Додано інформацію про ідентифікатор зміни ("shift_id") у відповіді на завдання 18 (
"task": 18).
Якщо зміна закрита - буде повенуто ідентифікатор попеоедньої зміни. Якщо зміна відкрита - ідентифікато поточної. - Виправлено помилку з відображенням сум по чекам переказу коштів в періодичних звітах якщо цих чеків не було сформовано.
- Додано можливісто виконати X-звіт для терміналів по протоколу
SimPays ККМ(Sense банк, Банк ТАС) - Прибрано повторний запуск час затримки перед фіскалізацією офлайнових чеків, якщо уже в межах одного періоду роботи каси в режимі офлайн він був запущений.
- Виправлено помилку з пошуком чеків лише за останні 4 зміни замість всіх при виконанні завдання 23 (
"task":23) по ПРРО. - Випралвено помилку з сумами по операціям продажу, повернення та скасування без урахування копійок на виконання X та Z звітів по терміналам на BPOS1 протоколі (Ощадбанк, Укрсиббанк, Банк Південний, Банк Восток, Sense банк, А-Банк).
- Розширено текст попередження про можливі наслідки при видаленні чеків.
- Виправлено помилку з неможливістю коректно створити принтер чеків в додатку при роботі на деяких версіях MS SQL та postgresql.
5.195.2 - hotfix від 11.04.2024
- Виправлено помилку при запуску додатку після оновлення на застарілих версіях Windows.
- Виправлено проблему із записом логів роботи додатку що при великому навантаженні призводило до зависання сервісу і необхідності його ручного перезапуску.
- Виправлено помилку з форматом дати при виконанні періодичних звітів при використанні БД SQLite.
- Виправлено помилку при збереженні службових чеків при виконанні зворотної синхронізації.
- Виправлено помилку при відображенні підсумків по видам оплат(якщо їх кілька) по операціям видачі готівки держателям ЕПЗ у візуалізаціх X, Z та періодичних звітів.
5.195.1 - hotfix від 11.04.2024
- Виправлено помилку із запуском додатку на деяких системах linux після оновлення.
5.195 - release від 10.04.2024
- Додано можливість фіскалізувати нові типи чеків: Чек переказу коштів(
"task": 15) та чек видачі коштів при переказі("task": 16).
У X, Z та в періодичних звітах додано блок"Операції переказу коштів та видачі коштів при переказі"з підсумком по даним операціям по видам оплат. - Змінено схему фіскалізації черги офлайн чеків після закінчення масових збоїв АЦСК та ДПС або в разі відсутності інтернету у разі роботи Device Manager як сервер ПРРО для розподілення та зменшення навантаження додатком на сервер допоки всі чеки не будуть фіскалізовані.
- Додано додаткові налаштування друку для принтерів:
-Режим встановлення кодової сторінки- в разі друку в режимі тексту замість картинки, Альтернативний режим вирішує проблему на первних моделях принтерів з наявними зайвими символами "Iя" в першому рядку чеку при встановленні кодування тексту на принтері.
-Спосіб друку зображень- в разі друку картинкою.Альтернативнийрежим дозволяє налаштувати коректний друк на принтерах де картинка друкувалась некоректно(замість чеку друкувася набір символів). Перевірено на принтерахBTPтаHPRT. РежимДля розфіскалізованих РРОдозволяє друкувати чеки картинкою на розфіскалізованих РРО. Перевірено на моделіEP-700(FP-700)
- Додано можливість підключати терміналі
Банку ТАСтаSense банкупо мережі по протоколуSimPays ККМза допомогогою TCP серверу. При створенні пристрою потрібно вказати порт серверу будь який доступний в системі і піля того повідомити банку налаштувати підключення до каси на ip адресу вашого пристрою(ноутбук чи комп'ютер) та вказаний в налаштуваннях порт. Після встановлення налаштувань банком можна працювати з терміналом.
- Виправлено помилку з сумою бази оподаткування 0 грн. для груп з 0% податку в значеннях
base_tax_sum_p,base_tax_sum_m,base_ex_sum_p,base_ex_sum_mв JSON відповіді при виконанні X, Z та періодичних звітів в масивіinfo.taxes. - Додано можливість фіскалізовувати чеки з нульовою сумою на наявними товарами при вказанні 100% знижки або знижки на всю суму товара чи чеку. Не важливо як саме буде передана знижка на весь чек чи на кожен товар окремо, сумова чи відсоткова, головне щоб сума до оплати після всіх знижок була 0.
Для того щоб дозволити фіскалізацію таких чеків потрібно в об'єктfiscal.receiptв json запиті передати"allow_zero_sum": true. В іншому випадку при спробі фіскалізувати чек з нульовою сумою буде повернуто помилку:
"res": 1133,
"res_action": 3,
"errortxt": "Фіскалізація чеків з наявними товарами та нульовою сумою заборонена. Для фіскалізації такого чеку необхідно передати \"allow_zero_sum\": true в об`єкт fiscal.receipt",
Передавати "allow_zero_sum": true обов'язково тільки у випадках якщо загальна сума чеку після всіх знижок буде 0, якщо сума до сплати буде не 0 - передавати "allow_zero_sum": true не потрібно.
Фіскалізація "нульових" чеків без товарів та оплат працює без змін.
Приклад запиту (Знижка 100% на весь чек)
{
"ver": 6,
"device": "postgres1",
"tag": "",
"type": 1,
"fiscal": {
"task": 1,
"receipt": {
"sum": 4000,
"allow_zero_sum": true,
"discounts": [
{
"disc": 100,
"disc_type": 1,
"disc_name": "Знижка 100% на весь чек. приклад"
}
],
"round": 0,
"rows": [
{
"code": "185",
"name": "Товар 1",
"cnt": 1,
"price": 1000,
"cost": 1000,
"discounts": [],
"taxgrp": 1
},
{
"code": "187",
"name": "товар 2",
"cnt": 1,
"price": 3000,
"cost": 3000,
"discounts": [],
"taxgrp": 1
}
],
"pays": [
{
"type": 0,
"sum": 0
}
]
}
}
}
- Виправлено помилку при увімкненні авторизації для доступу до вебінтерфейсу якщо до цього в попередніх версіях застосунку не було увімкнено дану авторизацію.
- Блокування створення ПРРО на кількох пристроях (в кількох додатках) одночасно. У випадку якщо ПРРО уже було створено в одному із Device Manager спрооба створити в наступному буде неуспішна:
{
"res": 2022,
"errortxt": "ПРРО наразі використовується іншому на пристрої. Перед створенням каси видаліть її з попереднього пристрою після чого поверніться до створення. Якщо до попереднього пристрою більше немає доступу - зверніться до служби підтримки Вчасно.Каса для розблокування."
}
Для зняття блокування необхідно видалити ПРРО з попереднього додатку Device Manager або, якщо доступу до попереднього додатку немає - звернутись на техпідтримку сервісу Вчасно.Каса.
9) Можливість зміни розділювача для числових значеннь в друкованих формах. Стандартно розділювач ,.
10) Можливість відключити перевірку готівки в касі("safe") при видачі решти("change") в чеках продажу/повернення та переказу коштів. Для цього в об'єкт fiscal.receipt в json запиті необхідно передати "not_check_safe": true. В такому разі перевірка доступного залишку при видачі решти не буде відбуватись.
11) Можливість виконати X, Z звіти по терміналу по протоколу BPOS1 для всіх мерчантів, при передачі в json запиті "merch": 0.
12) Заборонено запускати Примусовий запуск реєстрації чеку переходу в онлайн ("task": 9) в разі якщо уже виконується фіскалізація офлайн чеків.
13) Допрацювання фільтру по даті для періодичного звіту по датам ("task": 13):
- Можливість вказувати повну дату та час в форматі YYYYMMDDHHMMSS, наприклад:
"dt_from": "20240408091021",
"dt_to": "20240408211021",
У разі вказання лише дати YYYYMMDD без часу, наприклад "dt_from": "20240401" та "dt_to": "20240405" буде вибрано всі звіти, дата закриття яких буде в проміжку між 01.04.2024 00:00:00 та 05.04.2024 23:59:59.
- у вибірку звітів потрапляють звіти, дата формування яких знаходиться в проміжку між
"dt_from"та"dt_to".
- Допрацювання друкованих форм чеків та всіх звітів:
- Додано відображення номеру Z-звіту біля напису "Z-звіт";
- Додано блок
“Виручка“з порахованою сумою доходу по видам оплат за результатом суми всіх чеків продажу - чеки повернення - видача готівки держателям ЕПЗ + операції переказу коштів - операції видачі коштів при переказі; - Додано відображення залишоку готівки на початок зміни біля поточного залишку готівки в касі;
- Додано в періодичні звіти (
"task": 12,"task": 13) денний обіг з урахуванням округлення по продажам та додано обіг по чекам повернення. - Додано блок з інформацією по зміні:
Дата та час відкриття зміни;
Дата та час закриття зміни;
Номер останнього чеку в зміні. - Змінено назву звітів (
"task": 12,"task": 13) на "Періодичний звіт (повний)" та додано відображення номерів та дати першого та останнього звітів у вибірці. - Приведено відображення будь яких дат та часу в чеках та звітах до єдиного формату:
dd.MM.yyyy hh:mm:ss.
- Зміни в JSON відповіді:
- Додано при фіскалізації чеків продажу/повернення та переказу коштів суму товару після застосувань всіх знижок до даного товару(
"cost_after_disc") в масивіinfo.printinfo.goods. - Додано значення локального номеру ПРРО('"dfs_local_number"') у відповідях на всі завдання фіскалізації чеків та звітів в об'єкті
info.printinfo. - Додано масив об'єктів
incomeв об'єктіinfoз порахованою сумою "Виручки" за зміну по видам оплат для всіх звітів. - Додано в об'єкті
info.summaryзначення виручки загальної (income_p) після обрахунку суми виручки по видам оплат для всіх звітів. - Додано в масив об'єктів
info.reportsдля періодичних звітів суму по чекам продажу з урахуванням округлення ("roundsum") та суму по чекам повернення ("returnsum"). - Додано в усі періодичні звіти номери звітів від(
"n_from") та до("n_to") що потрапили у вибірку в об'єктіinfo, та дати першого("open_shift_dt") та останнього("close_shift_dt") звітів.
- Додаткові інфраструктурні допрацювання для більшої стабільності роботи додатку.
5.194.2 - patch від 14.02.2024
- У візуалізації чеків буде відображатись тип торгової точки додатково до її назви у рядку 2.
- У візуалізації чеків на внесення та винесення готівки вилучено відображення QR-коду.
- Додано перевірку поточної суми готівки у касі в разі оплати готівкою (
"type": 0) та передачі суми решти ("change") > 0 для чеків на продаж. Якщо передана сума решти > ніж поточна сума готівки в сейфі (в касі) буде повернуто помилку при фіскалізації чеку:
"errortxt": "У касі недостатньо коштів для проведення даної операції"
5.194.1 - patch від 09.02.2024
- Виправлено помилку з блокуванням ПРРО з помилкою "Пристрій зайнятий" на всі наступні запити у разі якщо додаток отримав запит на ПРРО після запуску до завершення ініціалізації бібліотеки підписання.
Для таких випадків додаток у відповідь по API буде повертати натупний json з описом помилки:
{
"ver": 6,
"source": "",
"device": "postgres1",
"tag": "",
"task_status": 3,
"type": 1,
"task": 18,
"dt": "20240208165440361",
"res": 1016,
"res_action": 1,
"errortxt": "Internal error: Бібліотека ЕЦП ще не ініціалізована. Зачекайте та спробуйте ще раз.",
"aq_errortxt": "",
"warnings": []
}
- Додано очищення сформованих чеків та офлайн номерів по ПРРО в разі видалення ПРРО із застосунку.
- Виправлено помилку з відображенням назви для знижки якщо назву не передано в запиті при передачі знижок за допомогою масиву
"discounts". - Допрацювання завдання 23 для пошуку/друку раніше фіскалізованого чеку по його фіскальному номеру.
Приклад запиту
curl --location 'http://localhost:3939/dm/execute-pkg' \
--header 'Content-Type: application/json' \
--data '{
"ver": 6,
"source": "DM_API",
"need_pf_img": 2,
"device": "postgres1",
"type": 1,
"fiscal": {
"task": 23,
"fiscal_number": "TEST_IMkWddWkHpi9tg"
}
}'
Можна використовувати при відправці запиту на ендпоінти для отримання інформація або додатково друку на принтері: /dm/execute, /dm/execute-prn, /dm/execute-pkg
Якщо чек, в даному випадку з фіскальним номером TEST_IMkWddWkHpi9tg не було знайдено буде отримано у відповідь помилку:
"errortxt": "Чек з фіскальним номером TEST_IMkWddWkHpi9tg не знайдено"
5.194 - release від 05.02.2024
-
Додано в підтримку нові банки та додаткові протоколи для існуючих банків при роботі з терміналами:
-А-Банк- додано можливість підключати термінали за допомогою протоколуJSON;
-Банк Південний- додано можливість підключати термінали за допомогою протоколуBPOS Light;
-Укрсиббанк- додано можливість підключати термінали за допомогою протоколуBPOS Light;
-Банк Восток- додано можливість підключати термінали за допомогою протоколуBPOS Light;
-Банк Sense- додано можливість підключати термінали даного банку що використовують протоколиBPOS1,POSAPIтаSimPays ККМ;
-Банк ТАС- додано можливість підключати термінали даного банку за допомогою протоколуSimPays ККМ. -
Додано можливість друкувати додаткову текстову інформацію та різного типу коди в формі чеків на продаж (
"task": 1) та на повернення ("task": 2).
Підтримувані типи кодів:
-QR-код
-code128
-ean13
Для передачі даної інформації використовується масив об'єктів"lines"(кожен код чи текст передається окремим об'єктом з параметрами в масиві) в об'єкті"fiscal"в json запиту на фіскалізацію чеку (аналогічно функціоналу в завданні 5 ("task": 5), але з додатковими параметрами розміщення в чеку та налаштуваннями).
Можливості налаштування:
-"qr_type"- тип. 0 - текстова інформація, 1 - штрихкод (ean13), 2 - штрихкод (code128), 100 - QR-код.
-"t"- текстова інформація. При"qr_type": 0- просто текст для відображення в формі чеку, інні значення - інформація що буде поміщена у відповідний код.
-"position"- позиція для відображення інформації. 1 - перед чеком, 2 - після "хедера" чеку, 3 - перед сумою чеку, 4 - перед "футером" чеку, 5 - після "футера чеку". Додаткові позиції будуть додаватись по запитам на техпідтримку.
-"qr_p"- розмір коду у % до ширини стрічки (не використовується якщо"qr_type": 0). 100 - вся ширина чеку, 75 - 75% ширини чеку для штрихкодів і так далі, для QR-кодів змінюється ширина та висота.
-"qr_height"- висота штрихкоду (не використовується якщо"qr_type": 0або"qr_type": 100). 1 - висота 0.5см., 2 - висота 1.3см., 3 - висота 2см.
-"qr_print_txt"- друк текстового представлення інформації в коді під самим кодом знизу (не використовується якщо -"qr_type": 0) false - не друкується, true - друкується.
-"align"- вирівнювання відносно чеку якщо"qr_p"менше 100 (в поточній версії не використовується якщо"qr_type": 0текст за замовчуванням - зліва). 1 - зліва, 2 - по центру, 3 - з правого боку.
Позиції:
Важливо! дана інформація буде відображатись лише в візуалізації чеків та на друкованих чеках з додатку(в тому числі друковані форми різного формату) та не передається в ДПС навідміну від коментарів в чеку.
- У відповіді на завдання відкриття зміни по ПРРО (
"task": 0) повертається id зміни"shift_id"у форматі uuid. Id зміни можна використати для перегляду інформації по чекам в зміні через ендпоінт/dm/vchasno-kasa/api/v1/shiftdocs?shift_id= - Виправлено відображення знижок та податків у чеках та звітах що було сформовано на попередніх версіях застосунку.
- Виправлено відображення баз оподаткування(поле "Обіг") для податкових груп де включено податок та додатковий збір(наприклад Акциз) у візуалізаціях звітів (X, Z, періодичний звіт по номерам, періодичний звіт по датам).
- При помилці підключення до бази даних у разі проблем з доступністю бази чи проблем з самою БД додаток буде запускатись і пробувати повторно підключитись до бази даних 1 раз в 30 секунд.
В цей час у відповідь на всі API завдання додаток буде повертати інформацію про помилку яка не дає продовжити запуск додатку. - Виправлено помилку зі збереженням лише останніх 2-ух файлів логів за день.
- Встановлено таймаут в 5 секунд на очікування відправки даних для друку на принтер, та виконано допрацювання для стабільності роботи.
При роботі через/dm/execute-prn,/dm/execute-pkgякщо за 5 секунд не вийде з'єднатись з принтером буде повернуто відповід на завдання по ПРРО, також в об'єкті"info"значення"isprint"буде рівне 0, тобто чек не було надруковано. - Для терміналів банків, що мають кілька доступних протоколів додано можливість обрати при підключенні потрібний
- Додано інформаційне повідомлення у разі якщо протокол терміналу або сам термінал не повертає список мерчантів проте, термінал працює та може проводити оплати.
- Виправлено помилку у відповіді на завдання фіскалізації чеку коли знижка на чек в масиві
"disconuts"сумувалась зі знижкою на весь чек переданою без масиву. - Зроблено оновлення бібліотеки та встановлення налаштувань для стабілізації роботи з базою даних SQLite.
- Додано відображення коректної помилки для терміналів на протоколі BPOS1 якщо COM порт вказаний в налаштуваннях терміналу існує, проте це не термінал.
- Виправлено відображення розділювальних ліній у візуалізації чеків на продаж/повернення.
- Додано нові параметри згідно вимог НБУ для виконання p2p переказів(
"task": 4) для терміналів Ощадбанку:
”rec_name”: - ім'я отримувача латиницею.
”rec_surname”: - прізвище отримувача латиницею.
”rec_pan”: - PAN(номер картки) отримувача. - Прибрано валідацію у вебінтерфейсі на введення числових значень на сторінці пакетного режиму в полі для введення номеру мерчанту.
- Додано підсказки у випадаючих списках з доступними в системі пристроями при підключенні принтерів по Bluetooth та COM та при підключення терміналів по COM.
- Додано коректну помилку у відповідь якщо для терміналів Приватбанку відключена можливість здійснювати певні операції із доступних в ДМ.
5.193.1 - hotfix від 13.12.2023
- Виправлено помилку з виконанням X/Z звіту після оновлення додатку при відкритій зміні по ПРРО.
- Виправлено помилку з розрахунком бази оподаткування в масиві
"taxes"в тегах"base_tax_sum_p","base_tax_sum_m","base_ex_sum_p", та"base_ex_sum_m"для податкових груп.
5.193 - release від 12.12.2023
-
Додано підтримку Arch linux.
-
Зменшено максимальний таймаут на очікування відповіді від кабінету Вчасно.Каса при фіскалізації чеків до 10 секунд (5 секунд встановлення з'єдання, 10 секунд очікування відповіді після з'єднання).
-
Додано функціонал перевірки ключа ЕЦП при додаванні ключа до ПРРО через вебінтерфейс.
Якщо ключ було зчитано успішно - одразу буде запущена автоматична перевірка реєстрації даного ключа в ДПС для підписання чеків. У разі якщо по результату відповіді від ДПС ключ не зареєстровано - буде запропоновано заповнити заявку на реєстрацію даного ключа для роботи ПРРО.
Для тестових ПРРО перевірка ключа не виконується.
У разі якщо ключ не зареєстровано, після його успішного зчитування в додатку буде відображено наступне повідомлення:
-
Додано можливість підключати термінали А-Банку та Банку Південний по протоколу BPOS1. Інші протоколи які підтримуються даними банками будуть доступні в наступній версії.
-
Додано можливість по API передавати масові знижки на чек чи на позицію. Кілька знижок передається за допомогою масиву об'єктів
"discounts". Можна передавати знижки як ранінше, або передавати лише масивом, або комбінувати з передачею масивом, аналогчно як з акцизними марками"code_a"та"code_aa".
Всі відсоткові знижки на позицію чи на весь чек нараховуються послідовно. Тобто якщо є 2 знижки, наприклад, 20% і 10% - сума по чеку чи по позиції після застосування першої знижки 20% буде використана як база для застосування знижки 10%.
Приклад запиту чеку з масивом знижок
{
"ver": 6,
"source": "API",
"device": "postgres1",
"need_pf_img": 2,
"type": "1",
"userinfo": {
"email": ""
},
"fiscal": {
"task": 1,
"cashier": "Касир 1",
"receipt": {
"sum": 17000.00,
"disc": 3000,
"disc_type": 0,
"disc_name": "Бонусна система",
"disc_apply_type": 3,
"discounts": [
{
"disc": 3000,
"disc_type": 0,
"disc_name": "Використання сертифікату №111 на 3000грн.",
"disc_apply_type": 1
},
{
"disc": 3000,
"disc_type": 0,
"disc_name": "Використання сертифікату №222 на 3000грн.",
"disc_apply_type": 1
}
],
"rows": [
{
"code": "100",
"code1": "79545322",
"code2": "45632",
"code_a": "S5556667w",
"name": "Продкут \"1\"",
"cnt": 1,
"price": 22000,
"cost": 22000,
"disc": 0,
"disc_type": 0,
"disc_name": "",
"disc_apply_type": 3,
"discounts": [
{
"disc": 3000,
"disc_type": 0,
"disc_name": "Бонуси",
"disc_apply_type": 3
},
{
"disc": 2000,
"disc_type": 0,
"disc_name": "Акція",
"disc_apply_type": 3
}
],
"taxgrp": 3,
"comment": "Коментар до продукту 1"
}
],
"pays": [
{
"type": 2,
"sum": 8000,
"paysys": "VISA",
"rrn": "1235567377",
"cardmask": "1223******1111",
"term_id": "SK014677",
"bank_id": "БАНК",
"auth_code": "AA12345678",
"comment": "коментар до оплати картою"
}
]
}
}
}
Приклад друкованої форми чеку
- Додано обмеження на видалення чеку з ДПС якщо останній чек уже було видалено до цього. Можна видалити лише один чек, після чого для видалення потрібно зареєструвати новий чек, інакше видалення буде заборонено.
- Виправлено помилку з аварійним завершенням роботи додатку при відправці запиту на термінал що використовують протокол POSAPI (Райффайзенбанк, ПУМБ) x32 розрядної версії на Windows.
- Виправлено помилку при передачі залишку готівки в касі в кабінет Вчасно.Каса якщо увімкнено передачу залишку та зміну було відкрито в офлайні.
- Виправлено помилку при спробі пошуку терміналу при його створенні в додатку на бд MS SQL.
- Виправлено помилку відправки суми на термінал на копійку менше актуальної суми оплати для протоколів BPOS1 та POSAPI.
- Виправлено помилку при оновленні додатку поверх з старої версії на нову через інсталяційний пакет на Windows.
- Додано перемикач "Очікування опрацювання терміналом попереднього запиту перед наступним" в налаштуваннях терміналів Приватбанку. Параметр встановлює очікування в 4 секунди перед кожним запитом на термінал.
Потрібно обов'язково увімкнути для роботи на терміналі
Verifone VX520від Приватбанку.
-
Виправлено помилку з відображенням коректного номеру мерчанту в разі якщо номер, встановлений банком, більше 10 знаків.
-
Можливість змінювати максимальну та мінімальну кількість офлайн номерів для роботи ПРРО в режимі офлайн.
Мінімальна кількість - кількість при досягненні якої буде виконано запит номерів в ДПС.
максимальна кількість - та кількість яка запитується в ДПС (наразі максимально можливо встановити 20000 номерів на один ПРРО).
Поточні налаштування будуть отримані з Кабінету Вчасно.Каса і відображатимуться в блоці "Інформація про ПРРО"
-
Додано перепідключення до postgresql бази у разі обриву з'єднання з боку БД при активній сесії.
-
Змінено текст помилки для терміналів що працюють по протоколу BPOS1 у разі якщо не вдалось обробити код помилки:
Повідомлення від банку: Операція неуспішна. Код відмови %s
%s - буде замінено на код відповідці процесингового центру банку отриманого від терміналу. -
Додано параметр
IgnoreConnErrorв секцію[Database]в конфігураційний файл для примусового запуску додатку в разі помилки підключення до бази даних. Можна використовувати у випадках коли база дани і додаток знаходяться на різних пристроях і при старті додатку не встигає запуститись база даних.
У разі встановленняIgnoreConnError=1додаток після запуску 1 раз в 30 секунд буде виконувати спробу підключитись до бази даних та виконати всі необхідні запити для отримання даних із БД.
Якщо підключення до бази даних не було виконано у відповідь на всі API методи буде повернуто помилку, наприклад:
{
"ver": 6,
"source": "",
"device": "",
"tag": "",
"task_status": 3,
"type": -1,
"task": -1,
"dt": "20231211141310542",
"res": 1130,
"res_action": 3,
"errortxt": "Виникла помилка при підключенні до БД: Cannot connect to server on host 'localhost':\r\nПодключение не установлено, т.к. конечный компьютер отверг запрос на подключение.\r\nSocket Error Code: 10061($274D)",
"aq_errortxt": "",
"warnings": []
}
У разі якщо підключення буде виконано можна працювати з ПРРО та пристроями як зазвичай.
Параметр
IgnoreConnErrorне сумісний ізServiceName. Дозволено використовувати лише один.
-
У json відповідь по API на викоання X/Z та періодичних звітів було додано окремі параметри в масив об'єктів
"taxes"в значенні яких будуть бази оподаткування для податкових груп із додатковим збором.
"base_tax_sum_p"- база оподаткування по основному податку (наприклад ПДВ 20%) по чекам продажу.
"base_tax_sum_m"- база оподаткування по основному податку (наприклад ПДВ 20%) по чекам повернення.
"base_ex_sum_p"- база оподаткування по додатковому збору (наприклад Акциз 5%) по чекам продажу. Якщо податкова група не має додаткового збору - завжди 0.
"base_ex_sum_m"- база оподаткування по додатковому збору (наприклад Акциз 5%. Якщо податкова група не має додаткового збору - завжди 0. -
В фіскальних чеках QR-код тепер містить посилання на візуалізацію чеку в кабінеті ДПС (https://cabinet.tax.gov.ua/cashregs/check) з додатковими обов'язковими параметрами:
ФН чеку(id),
дата (date),
час (time),
фіскальний номер ПРРО (fn),
сума чеку (sm),
контрольне число (mac)
Приклад:
https://cabinet.tax.gov.ua/cashregs/check?id=TEST_OFN_WeBKHz774mvTOQ&date=20231207&time=10:51:36&fn=3&sm=8000&mac=c1d019bc8d1dce852e371e0149b8655627f247fcc7160deb6ab953c3522f4919
У тестових чеках QR-код містить посилання на кабінет Вчасно.Каса (https://kasa.vchasno.ua/) з додатковими реквізитами.
Приклад:
https://kasa.vchasno.ua/c/TEST_VbS7yd6TPtgdqw?MAC:c086300d35d95c67b0b47fba07bc91098a8c87b44f3c1c2aeecc1df4c40d7624;DT:20-12-2023T14:55:14;FR:TEST_VbS7yd6TPtgdEw;SUM:17000;FN:400000000
-
Встановлено налаштування підключення для більш стабільної роботи бази даних sqlite при раптових збоях в живленні комп'ютеру при фіскалізації чеку.
-
Додано очікування в 10 секунд перед запуском автоматичної очистки чеків при закритті зміни.
5.192.1 - hotfix від 06.11.2023
- Виправлено помилку із запуском бібліотеки підписання при старті застосунку на Linux.
- Виправлено помилку при відправленні запиту на оплату по терміналам Приватбанку.
5.192 - release від 06.11.2023
- Очистка чеків відбувається після закриття зміни та повернення відповіді по звіту по API, для отримання відповіді по z-звіту в межах стандартного таймауту на відповідь у POS системі, якщо очистка займає багато часу.
Звертаємо увагу що якщо у вас використовуєтсья стандартна база даних sqlite після запуску очистки, тобто після закриття зміни по конкретному ПРРО, можуть бути затримки у відповідях на наступні завдання поки не завершиться процес очистки.
-
Зміна процесу отримання сертифікатів ключів ЕЦП та процесу оновлення кореневого сертифікату для стабільної роботи ключів ЕЦП у разі оновлення сертифікатів з боку АЦСК.
-
Виправлено проблему при спробі відкрити зміну якщо по касі сталась помилка при отриманні офлайн номерів до відкриття зміни.
-
Виправлення оновлення налаштувань по касі та податкових груп і типів оплат з кабінету Вчасно.Каса при відкритті зміни по ПРРО якщо по ПРРО виконувались службові завдання до відкриття зміни.
-
Оновлено бібліотеку підписання iit до актуальної версії.
-
Виправлено відправку суми до оплати на термінал на 1 копійку менше ніж в запиті для терміналів Ощадбанку, Укрсиббанку, Банку Восток, Райффайзенбанку, Банку ПУМБ.
-
Виправлення роботи Зворотної синхронізації.
-
Виправлено помилку при спробі запросити документи за конкретну зміну (
/dm/vchasno-kasa/api/v1/shiftdocs) з параметром відображення сервірсних чеків (service=1). -
Метод /dm/vchasno-kasa/api/v1/settings замінює лише ті налаштування що передані в запиті без скидання до стандартних налаштуваннь параметрів що не передані в запиті.
-
Додано інфоромацію про поточні ліміти часу роботи в офлайні для ПРРО.
-
Виправлено помилку з відсутністю кодування windows-1251 в XML чеку.
-
Виправлено проблему з отриманням відповіді від терміналів Приватбанку.
-
Для терміналів Приватбанку, за замовчуванням, відключено можливісь асинхронного запиту статусу поточної операції з терміналу. Для включення даної можливості потрібно перейти в налаштування терміналу та увімкнути перемикач
-
Виправлено помилку при обрахунку сум по документам за зміну на postgresql версіях 10+.
-
Виправлено помилку з екрануванням апострофа (
') в назві ПРРО та пристроїв. -
Виправлено розрахунок
"sum"для чеків продажу/повернення для методу/dm/vchasno-kasa/api/v1/shiftdocs -
Додано розрахунок суми по продажам/поверненням та податкам для методу
/dm/vchasno-kasa/api/v1/shiftsпри відкритій зміні по ПРРО. -
Виправлено помилку з відображенням в друкованій формі Z-звіту що звіт видано в режимі офлайн якщо перехід в офлайн відбувся на фіскалізаціх звіту в ДПС.
-
Розширено таймаут до 5 секунд на встановлення з'єдання з терміналами Приватбанку.
-
Авторизація, якщо увімкнена в налаштуваннях, тепер працює на всі методи що мають в ендпоінті:
/dm/api/v1/
/dm/api/v2/
/dm/api/v3/ -
Додано можливість вказувати назви для знижок на товар та весь чек для відображення назви в чеку за допомогою тегу
"disc_name". -
Додано можливість передавати тип застосування знижки для застосування знижки як фактично знижки на товар, або для застосування її як зменшення на суму передплати у випадку використання змішаної форми оплати (передплата/післясплата за товар) за допомогою тегу
"disc_apply_type".
Приклад:
Знижка на товар
"disc": 50,
"disc_type": 1,
"disc_name": "Передплата",
"disc_apply_type": 1,
Знижка на весь чек
"disc": 50.00,
"disc_type": 1,
"disc_name": "Акція",
"disc_apply_type": 3,
Друкована форма:
Z-Звіт (розділ "Знижки")
5.191 - release від 29.09.2023
- Додано новий банк для підключення терміналів - Банк ПУМБ.
- Можливість встновити Device Manager для роботи на Arch Linux.
- Перезапит офлайн номерів у фоновому режимі. Додатково до отримання офлайн номерів при відкритті зміни та при виході з офлайну тепер помери будуть поповнуватись додатково якщо каса онлайн та номерів немає або менше як 1500. Періодичність запиту якщо номери не були отримані від ДПС - 1 раз в кожні 10хв. не залежно чи зміна відкрита чи закрита.
- Додано можливість отримати інформацію про останню проведену транзакцію по терміналу за допомогою ендпоінту
/dm/lasttransaction. Інформації по останній транзакції буде повернута в JSON форматі. Структура аналогічна як і мала б бути у відповіді на оригінальний запит. - Додано можливість асинхронно отримувати статус поточної активної операції від терміналу через енпоінт
/dm/transaction-status. Якщо по терміналу є активна операція у відповідь на запит буде надано статус код від терміналу та текстовий опис статусу поточної операції для виводу на екран касиру чи клієнту будь то оплата чи інша операція. - Можливість пошуку терміналу в мережі або через COM при створенні терміналу в додатку. Можливість знайти лише один термінал або кілька якщо вони підключені. Пошук за замовчуванням буде відбуватись у ті й же підмережі для якої підключений пристрій де встановлено ДМ.
- Розширено функціонал пакетного режиму:
- При підключеному терміналі можливість проводити повернення/скасування оплати по терміналу та чек повернення по ПРРО та виконувати x/z - звіти з терміналу і ПРРО одночасно.
- При підключеному принтері можливість друкувати всі документи і чеки що мають друковану форму.
- Можливість в налаштуваннях пакетного режиму при роботі з терміналом обрати при яких типах(кодах) оплати переданим в запиті буде відправлено запит на термінал. Можливість обрати кілька типів оплат замість стандартного типу 2 Картка.
- Збереження логів по роботі терміналів в окремій директорії.
- Відключення ПРРО у разі проблем в роботі та можливість відключити/включити ПРРО вручну. У разі якщо ПРРО повторно отримує помилки які не вирішуються без втручання(наприклад ПРРО скасовано в ДПС або змінено токен для ПРРО) ПРРО буле заблоковано для роботи і проведення подальших операцій до моменту вирішення проблеми.
Якщо відключити ПРРО вручну за допомогою кнопки "Заблокувати ПРРО" у вкладці "Інженерні функції" по ПРРО також буде заблоковано проведення чеків і інших операцій до моменту розблокування вручну. - Додано новий тип операцій: P2P перекази для протоколу BPOS1(Ощадбанк, Укрсиббанк, Банк Восток).
- Виправлено помилки отримані від терміналу для протоколу BPOS1(Ощадбанк, Укрсиббанк, Банк Восток) при виконанні операції продажу з видачею готівки та P2P переказу.
- Включено автоматичну очистку чеків старших 40 днів при встановленні ДМ на новий пристрій.
- Відображення всіх даних по еквайрингу в чеку та коригування форми чеків під розміщення всіх реквізитів.
- Коригування друкованої форми чеку видачі готівки держатетелям ЕПЗ.
- Коргування роботи автооновлення на всіх версіях linux.
- x64 APK версія додатку для android.
- Додано перевірку на мінусову суму в типах оплат при фіскалізації чеків. При відправці чеку з мінусовою сумою буде видано помилку.
- Додано перемикач для автоматичного відкриття/не відкритя грошового ящику при роботі через /dm/execute-pkg і /dm/execute-prn
- В реєстр змін і документів додано суму по продажам і поверненням окремо.
- Виправлено помилку при підключенні терміналів Укрсиббанку через COM порт.
- Додано можливість видалити останній проведений чек з ДПС та з додатку у разі помилкової фіскалізації.
- Виправлено помилку коли чек не надходив на пошту/viber/смс якщо чек видано в режимі офлайн, при цьому передано дані клієнта.
- Виправлено помилку при розрахунку бази сум податків при застосуванні знижок у випадку якщо вартість товару > суми чеку.
- Виправлено помилку коли сума(sum) документу(чеку) повертається без урахування загальної знижки на чек в реєстрі чеків для чеків продажу і повернення.
- Виправлено автоматичний розрахунок вартості товару в чеку якщо не передано cost.
- Розширено перелік файлів при ручній очистці сертифікатів ключів.
- Виправлено помилку з некоректними значеннями type і task у відповідь на завдання оплати по терміналам.
- Виправлено помилку зі зникненням створеного пристрою в інтерфейсі на sqlite.
- Виправлення нумерації чеків при передачі даних в ДПС якщо було здійснено перехід в офлайн та видалення службового дубля.
- Виправлено повернення мінусового залишку при виконанні task:18 для кас по яким не було проведено чеків і змін.
- Виправлено формування неповного списку мерчантів для терміналів Приватбанку.
- Виправлено помилку при повторному пошуку чека по tag на postgresql.
- Виправлено повторний друк чеку при передачі в запиті copies > 1
Зміни у версіях які більше не підтримуються: