Звідки взялася ця сума? Що робити, коли розрахунки сервісу не збігаються з вашими
Режим читання збільшує текст, прибирає всю зайву інформацію зі сторінки і дозволяє зосередитися на матеріалі. Тут ви можете вимкнути його в будь-який момент.
Чому сервіс показав саме цю суму — і як перевірити, чи немає помилки? Засновник MYFOP UA Антон Ляховський зіткнувся з цим питанням, коли один із перших користувачів помітив, що система не враховує повернення коштів. У колонці для Vector він розповідає, як виправив проблему, чому залишив остаточне рішення за користувачем і як зробити розрахунки в сервісі зрозумілими.
Коли підприємець бачить у сервісі суму, яка відрізняється від його власного розрахунку, кнопка «Оновити» мало допомагає. Потрібно зрозуміти, які операції потрапили до підсумку і що система з ними зробила. Інакше доведеться відкривати банківську виписку й рахувати все заново.
З цим я зіткнувся під час створення MYFOP UA, сервісу для обліку ФОП. Працюючи в IT, я вів власні доходи й податки в Google Sheets: спочатку автоматизував підвантаження валютних курсів, потім квартальні розрахунки. Наступним кроком став продукт із підключенням банку. Хотілося прибрати ручне перенесення даних, яке щомісяця повторювалося в таблиці.
Першу версію перевірили троє друзів. У двох результати зійшлися з їхніми даними, в одного ні. Він мав інтернет-магазин, користувався monobank і повертав гроші покупцям. Цей випадок виявив межі сценарію, який добре працював на моєму ФОП.
Історія з поверненням підказала питання для проєктування будь-якого продукту з розрахунками: що побачить людина, коли захоче перевірити конкретну цифру? Нижче розберу його на прикладі обліку. Та сама логіка стане у пригоді командам, які показують рекламні витрати, залишки товарів або нарахування за підпискою.
Одного мінуса у виписці недостатньо
Той тестувальник, мій друг Максим, порівнював доходи й транзакції у сервісі зі своїми даними. Він написав мені в чат, що знайшов важливу помилку: система не враховує повернення покупцям. І додав, що в неоднозначних випадках саме власник бізнесу може уточнити, до якої оплати належить конкретне повернення.
Я додав облік повернень і можливість пов’язати повернення з початковим платежем. Сервіс автоматично підбирає кандидатів, але самостійно їх не прив’язує. Остаточний вибір підтверджує користувач. До цього зв’язок не зберігається, а повернення не зменшує дохід у звіті.
Після розгортання нової версії Максим повторно перевірив звіт і підтвердив, що він правильно враховує повернення. Наскільки пам’ятаю, у нього було близько шести-семи таких операцій за квартал.
У цьому рішенні межа автоматизації проходить між пошуком і підтвердженням. Алгоритм скорочує перелік операцій, які треба переглянути. Людина підтверджує, що знайдений платіж справді стосується повернення. Для інтерфейсу це означає, що потрібно показати підстави для вибору та альтернативи, а не лише запропонувати натиснути кнопку.
Що саме означає рекомендація алгоритму
У нашому випадку пошук починається з вхідних платежів, здійснених не пізніше за дату повернення. Основним критерієм ранжування кандидатів є збіг суми з допуском до однієї одиниці порівнюваної суми. Порівнюється гривневий еквівалент, сума в тій самій валюті або загальна сума, яку можна витягти з фрази на кшталт «загалом … грн» у призначенні платежу.
Збіг суми додає кандидату 10 балів, той самий рахунок ФОП — ще 2, той самий банк — ще 1. За однакової кількості балів вище розташовується новіший платіж. Це визначає порядок показу. Вища позиція не доводить, що повернення належить саме цій операції.
Наприклад, кілька покупців можуть заплатити однакову суму. У поточному зіставленні відправник не враховується, а призначення не порівнюється за змістом: воно використовується для витягування загальної суми та ручного пошуку. Тому навіть збіг суми, рахунку й банку не замінює перевірки користувачем.
Саме тут є ризик для продукту: найзручніший для показу кандидат може виглядати як уже встановлений факт. Я розділив ці стани на рівні дії. Поки користувач не підтвердив вибір, система має лише пропозицію, яка не змінює підсумок доходу.
Як користувач перевіряє запропонований платіж
Найвище ранжований кандидат показується окремо під назвою «Автоматично знайдений платіж» із кнопкою «Підтвердити». Нижче є розділ «Обрати інший платіж». Там доступні решта кандидатів, зокрема інші операції з такою самою сумою.
У таблиці видно дату, рахунок, банк, валюту, квартал, суму, її гривневий еквівалент і призначення платежу. Користувач може змінити період пошуку або шукати за сумою, датою та призначенням. Ці деталі потрібні для конкретного рішення: чи повернули гроші саме за цю оплату.
Для мене важливий момент у такому інтерфейсі полягає в тому, що назва «знайдений платіж» звучить упевненіше, ніж результат ранжування. Тому можливість підтвердити рекомендацію або обрати інший платіж має суттєве значення.
Після підтвердження зв’язок зберігається за ідентифікаторами банківських операцій разом із кварталом початкового доходу. Сума допомагає знайти кандидата, але збережений зв’язок уже стосується конкретних операцій.
Якщо точний платіж знайти неможливо, користувач може вказати лише квартал отримання доходу. У такому разі сервіс ураховує повернення в обраному кварталі без прив’язки до конкретної оплати. Це інший рівень деталізації: система отримує рішення щодо періоду, але не повинна створювати враження, ніби початкову транзакцію знайдено.
Перевіряйте пояснення разом із розрахунком
У роботі над сервісом я використовував власні дані в таблиці як орієнтир і додавав тести для округлень, повернень, внутрішніх переказів, валютних операцій та підвантаження курсів з урахуванням вихідних. Окремо Максим перевірив виправлений звіт на своєму обліку.
Один із тестів логіки звіту перевіряє важливу межу: непідтверджене повернення не повинно зменшувати дохід. Це дозволяє перевіряти не тільки підсумкове число, а й стан, у якому система має право його змінити.
Для інтерфейсної перевірки я б додав до цього сценарій із кількома однаковими сумами: чи людина бачить альтернативи, розуміє, що пропозицію ще не підтверджено, і може вибрати інший платіж? Після зміни прив’язки варто звірити показану операцію з тією, яку використовує розрахунок.
Це вже перевірка узгодженості пояснення, дії користувача й даних, а не лише арифметики.
Що команда може перевірити вже зараз
На власному кейсі я виділив три запитання, які варто поставити до будь-якої рекомендації в продукті з розрахунками:
- За якими ознаками система запропонувала саме цей варіант і чого вона не враховує?
- Чи бачить людина інші варіанти та відрізняє пропозицію від уже підтвердженого рішення?
- Яка саме дія змінює дані й підсумок і як користувач може виправити свій вибір?
У моєму випадку відповіді втілилися в ранжуванні платежів, окремому списку альтернатив і підтвердженні до зміни доходу. Ці рішення не скасовують ризику помилки користувача, але дозволяють перевірити рекомендацію алгоритму перед тим, як вона вплине на розрахунки.
Початкова таблиця була зрозуміла мені, бо я сам збирав її формули й пам’ятав свої операції. У продукті цю пам’ять не можна вимагати від кожного користувача. Якщо людина сумнівається в результаті, інтерфейс має допомогти їй пройти шлях до конкретного платежу, правила чи налаштування. Там і з’являється можливість перевірити, чи варто покладатися на показану суму.
Більше про це
«Багато бізнес-ідей лежить у нас під ногами»: Вікторія Тігіпко про ринки, українських ангелів та помилки на пітчингах
Будь-яку статтю можна зберегти в закладки на сайті, щоб прочитати її пізніше.
Партнерські матеріали
