- API в обох сервісів є, але потрібні оплати, повернення й готовий конектор перевіряють окремо.
- Погодьте рахунки, категорії, філії та джерело кожного доходу, щоб банківський обмін не створював дублікати.
- До запуску звірте минулий місяць, повторну передачу та відновлення після збою.
Інтеграція Finmap з програмою клубу потрібна, щоб підтверджені оплати й повернення потрапляли в облік грошей без повторного введення. Для зв’язки LuckyFit і Finmap спочатку перевіряють доступні дані в обох системах, погоджують рахунки та категорії, а потім звіряють пробний період. Публічний API є в обох сервісів. Це ще не підтверджує готовий конектор або доступність усіх фінансових операцій LuckyFit.
Для власника результат має бути простим: видно, скільки грошей отримала кожна філія, що повернули клієнтам і які надходження ще очікуються від платіжного сервісу. Адміністратор працює у клубній програмі, фінансист перевіряє розбіжності. Нижче описано можливий процес обміну, а не вже реалізований Artbrain кейс LuckyFit → Finmap.
Що доводиться переносити після закриття зміни
Абонемент продано, разове заняття оплачено, гроші за скасовану послугу повернули. Після цього адміністратор відкриває фінансову систему й знову вводить суми. Потрібно розділити готівку, термінал і онлайн-оплати, вибрати статті доходів, не переплутати філію. Якщо частину роботи забирає бухгалтер або власник, між продажем і фінансовим звітом з’являється ще одна передача інформації.
Найскладніше перенести не загальну виручку за день, а її зміни. Повернення може пройти наступного тижня. Покупець може внести частину вартості зараз, решту пізніше. Продаж оформлюють в одному клубі, а тренування відвідують в іншому. Один підсумковий рядок приховує ці відмінності, хоча саме вони пояснюють розбіжності між касою, банком і звітом.
Типова ручна помилка не обов’язково виглядає як неправильна сума. Платіж внесли двічі, повернення пропустили, інкасацію записали доходом, а всі онлайн-надходження віднесли до головної філії. Загальний залишок іноді сходиться, але рішення про витрати чи результати клубів спирається на викривлені дані. Автоматизацію варто починати з переліку саме таких ситуацій.
Які можливості LuckyFit і Finmap підтверджені
LuckyFit: API є, фінансовий склад треба перевірити
LuckyFit офіційно повідомляє про відкритий API, тобто програмний спосіб обміну даними. У публікації наведені робота з клієнтами, продаж абонементів та отримання інформації про них. Є посилання на публічну технічну документацію. Наявність цього API сама по собі не доводить, що доступний повний журнал оплат і повернень з усіма потрібними полями.
Перед оцінкою потрібна перевірка конкретного кабінету: чи можна отримати фактичні платежі, їхні сталі номери, виправлення та повернення за минулий період. Окреме питання до постачальника: чи є webhook, автоматичне повідомлення про подію, саме для цих операцій. Підтвердженого набору таких повідомлень для потрібного сценарію ми не встановили. Обіцяти миттєвий обмін на цій підставі рано.
Finmap: API, імпорт і готові підключення
У документації Finmap описані створення доходів, витрат і переказів, рахунки, категорії, проєкти та webhooks. Є офіційний Excel-шаблон імпорту й каталог інтеграцій. Готову пару LuckyFit → Finmap у перевіреному каталозі не підтверджено. Її актуальну наявність та умови підключення треба уточнити в сервісів.
Готове підключення від постачальника варто перевірити першим. Попросіть показати не лише звичайний продаж, а й часткове повернення, повторне завантаження та розподіл між філіями. Якщо ці ситуації вже обробляються за вашими правилами, окрема розробка може не знадобитися. Назва інтеграції в каталозі ще не відповідає на питання про її фактичний обсяг.
Що саме має переходити в облік грошей
Одиницею обміну доцільно зробити підтверджений рух грошей. Створений абонемент, запланований платіж і фактичне надходження означають різні події. Зафіксуйте це в короткій таблиці відповідностей: яке поле клубної програми заповнює яке поле фінансової системи. Технічно таку таблицю називають мапінгом. Власнику потрібен її зміст, щоб перевірити правила до початку роботи.
- Номер операції та джерело. Дають змогу знайти початковий платіж і розпізнати повторну передачу.
- Сума, валюта, дата оплати. День отримання грошей відокремлюють від періоду дії абонемента.
- Спосіб оплати та рахунок. Готівку, термінал і онлайн-канал зіставляють з погодженими рахунками.
- Категорія і філія. Абонементи, персональні заняття та інші послуги розподіляють за узгодженими правилами.
- Повернення і комісія. Зберігають зв’язок з оплатою та окреме пояснення зменшення коштів.
Це перелік вимог до майбутнього обміну, а не обіцянка, що кожне поле вже доступне через LuckyFit. Відсутню інформацію не варто вгадувати за назвою послуги. Наприклад, якщо джерело не містить комісії, її беруть з погодженого звіту платіжного сервісу або залишають для перевірки. Невідому філію не підміняють головним клубом.
Також домовтеся, яка система відповідає за виправлення. Якщо адміністратор змінив спосіб оплати у джерелі, фінансовий запис має отримати погоджене коригування. Водночас ручний коментар фінансиста не повинен зникати після наступної синхронізації. Межа між автоматичними й ручними полями має бути зрозумілою обом працівникам.
Як не порахувати одну оплату двічі
Умовний приклад: клієнт оплатив абонемент на 2 000 грн онлайн, сервіс утримав 40 грн, на банківський рахунок прийшло 1 960 грн. Це навчальні числа, не тариф сервісу. Якщо внести 2 000 грн з клубної програми та ще 1 960 грн як новий дохід з банку, звіт покаже зайві гроші.
Один з можливих підходів: зафіксувати оплату на проміжному рахунку, окремо показати комісію, а надходження в банк провести як переміщення грошей. Конкретну схему погоджують з людиною, яка веде облік. Для кожного потоку має бути одне джерело створення доходу. Банківське підключення й клубний обмін не повинні незалежно створювати його за ту саму оплату.
Продаж, повернення та внутрішній переказ
Часткове повернення в умовному прикладі на 500 грн має зберегти історію первинної оплати. Не можна просто стерти продаж або змінити стару суму так, що закритий день перестане сходитися. Форма фінансового коригування залежить від погодженої моделі. Зупинений або заморожений абонемент також не означає автоматичного повернення грошей.
Внесення готівки з каси на банківський рахунок не створює ще один продаж. Оплата частинами переходить у рух грошей у міру фактичного отримання частин. Подарунковий сертифікат потребує окремого правила для надходження і подальшого використання. Такі рішення приймає відповідальна за облік людина. Сам обмін не визначає податки, фіскальні дії чи порядок визнання доходу.
Коли передавати операції та що робити без потрібного API
Періодичність залежить від доступного джерела й потреб власника. Якщо достатньо звірки після зміни, можна погодити обмін після її закриття. Якщо потрібна картина протягом дня, перевіряють можливість регулярного отримання нових і змінених записів. Передача за подіями можлива лише тоді, коли джерело справді надає відповідні повідомлення. Finmap webhook не створює відсутню подію в LuckyFit.
У звіті має бути видно останню успішну звірку та період, за який дані повні. Позначка «оновлено сьогодні» не допомагає, якщо пропущено ранкові повернення. Часові пояси й межу зміни погоджують заздалегідь: оплата після півночі не повинна випадково перейти в іншу добу лише через налаштування сервера.
Якщо API конкретного кабінету не віддає потрібні операції, залишаються три предметні варіанти:
- Перевірити з LuckyFit наявний експорт оплат і повернень, отримати зразок та погодити формат файла.
- Запитати постачальника про його готове підключення або розширення доступного обміну.
- Побудувати перетворення погодженого експорту у формат імпорту Finmap, якщо даних достатньо.
Доступність потрібного експорту LuckyFit треба підтвердити, це не встановлена тут функція. Файл, який працівник завантажує вручну, прибирає повторне введення рядків, але залишає ручний крок. Повністю автоматичний процес можливий лише з підтвердженим автоматичним отриманням джерела. Після зміни формату файла неперевірені рядки мають зупинятися з поясненням.
Яку звірку власник залишає за собою
Автоматичне перенесення не скасовує контроль. Перевіряти варто кількість і суму оплат, повернень та комісій окремо за філіями, рахунками й днями. Загальна сума мережі може зійтися навіть тоді, коли записи двох клубів поміняли місцями. Для готівки потрібне зіставлення з фактичною касою, для безготівкових оплат також з відповідним звітом про зарахування.
- Повнота: усі операції вибраного періоду отримані, включно з виправленими заднім числом.
- Відсутність повторів: кожна операція джерела має один погоджений результат у фінансовій системі.
- Розподіл: рахунок, категорія та філія відповідають таблиці правил.
- Винятки: відхилені записи мають причину й відповідального за виправлення.
Корисна перевірка починається з конкретного запитання: «Чому цей платіж не потрапив у Finmap?» За номером має знаходитися вихідний запис, результат передачі та причина затримки. Повідомлення «усе відправлено» без перевірки кінцевого запису недостатньо. Узгодьте також, хто перевіряє звірку у вихідний і хто заміняє цю людину під час відпустки.
Що станеться, коли сервіс перестане відповідати
Немає відповіді від Finmap, змінилися права або джерело повернуло помилку всередині успішної технічної відповіді. У цих ситуаціях день не можна позначати завершеним. Обмін повинен зберегти непередані операції, показати зрозуміле попередження відповідальній людині й дозволити продовжити роботу після відновлення доступу. Власник має бачити, за який період картина неповна.
Особливо небезпечна ситуація: запис прийнято, але підтвердження загубилося. Повторна спроба спочатку перевіряє вже створений результат за сталим ідентифікатором. Ідентифікатор означає постійний номер операції, однаковий у всіх спробах. Потрібний результат приймання простий: повторний запуск не збільшує виручку й не повторює повернення.
Необхідний доступ обмежують погодженими даними. Для перенесення виручки зазвичай не потрібні анкети відвідувачів або їхня історія тренувань. Ключі підключення передають узгодженим захищеним способом, а не додають до листування зі зразком звіту. Порядок заміни ключа та відновлення обміну записують в інструкції. Після зміни категорій або відкриття філії правила перевіряють повторно.
Чи можна передавати виручку клубу в QuickBooks Online
Для клубів за кордоном можливим напрямком є QuickBooks Online. В офіційному Accounting API описані SalesReceipt для оплаченої реалізації та RefundReceipt для повернення. Intuit також документує webhooks і підключення через OAuth 2.0: власник дозволяє застосунку доступ до обліку. Це підтверджує технічний шлях, але не готовий конектор LuckyFit і не однакову схему для всіх країн.
Перед реалізацією місцевий бухгалтер визначає потрібні документи й рахунки. Продаж з одночасною оплатою, рахунок з пізнішою оплатою та повернення потребують узгодженого відображення. Перевіряють компанію одержувача даних, валюту та податкові налаштування конкретного обліку. Не можна одночасно створювати оплачену реалізацію й незалежний платіж за ті самі гроші. Банківське підключення також перевіряють на повтори.
Заміна Finmap на QuickBooks Online не усуває обмежень джерела. Все одно потрібні підтверджені рухи грошей, повернення, філії та історія змін у програмі клубу. Пробу проводять у погодженому тестовому середовищі й перевіряють ті самі контрольні випадки. До живого обліку переходять після звірки, коли зрозуміло, який документ створюється для кожного типу події та хто його перевіряє.
Як перевірити майбутній обмін на минулому місяці
Для проби візьміть завершений місяць з типовими оплатами й хоча б тими винятками, які реально трапляються у вас. Погодьте вихідні підсумки до завантаження. Пробний перенос виконують в окремому погодженому середовищі, без повторного внесення в робочий облік. Якщо ізольованого місця немає, спочатку готують файл результатів для перевірки, без запису операцій.
- Зіставте звичайні оплати, часткові оплати та різні способи отримання грошей.
- Перевірте повернення іншого дня, невідому категорію й платіж без визначеної філії.
- Повторіть той самий набір: кількість записів і підсумки не повинні зрости.
- Змоделюйте недоступний сервіс, потім відновіть передачу та перевірте повноту.
- Зіставте результат у фінансовому журналі й звітах, а не лише статус виконання обміну.
Перед запуском визначте останній вручну внесений платіж і перший автоматичний. Якщо на перехідний період залишаєте ручну перевірку, не дублюйте самі записи. План зупинки також потрібен: хто призупиняє обмін, як зберігають нові операції та як повертаються до роботи без пропусків після виправлення.
Що може зробити Artbrain і з чого почати
На сторінці інтеграцій Artbrain описані підключення до систем, які ми розробляємо самі. Це межа поточної послуги. Готове налаштування будь-яких двох чужих сервісів ми тут не обіцяємо. Для цього сценарію можемо розглянути кастомну розробку окремого модуля обміну, якщо постачальники надають достатні дані й дозволяють потрібне підключення.
Починаємо з безкоштовного розбору задачі. На спільному перегляді обох кабінетів перевіряємо джерела, потім погоджуємо таблицю відповідностей, пробу на минулому місяці та умови ввімкнення. Фіксованої ціни такого модуля немає: індивідуальну письмову оцінку готуємо після обговорення обсягу й архітектури. Підписки та платежі постачальникам клієнт оплачує напряму, без нашої націнки.
Питання відповідальності після запуску варто узгодити разом із розробкою. Сторінка підтримки й доопрацювань пояснює формат супроводу; потрібні перевірки саме цього модуля фіксуємо окремо. Загальні помилки запуску розібрані в матеріалі про п’ять помилок автоматизації бізнесу. Тут критерієм успіху лишається звірена виручка з поясненими відхиленнями.
Для першого звернення достатньо назв програм, переліку способів оплати, опису філій та знеособленого зразка звіту. Паролі в першому повідомленні не потрібні. Напишіть, які операції сьогодні переносите вручну й коли хочете бачити повну картину грошей. Після перевірки буде зрозуміло, чи достатньо можливостей постачальників, чи варто будувати окремий модуль.
Часті питання
Чи є готова інтеграція LuckyFit і Finmap?
У перевіреному офіційному каталозі готову пару не підтверджено. Обидва сервіси публікують API, але доступ до всіх потрібних оплат і повернень LuckyFit треба перевірити. Спочатку уточнюють можливості постачальників, потім оцінюють потребу в окремому модулі.
Які дані потрібно переносити з програми клубу?
Підтверджені оплати й повернення з постійним номером операції, сумою, валютою, датою, способом оплати, рахунком, категорією та філією. Комісії переносять з погодженого джерела. Це вимоги до обміну: доступність кожного поля перевіряють окремо.
Чи можна передавати виручку автоматично в реальному часі?
Це залежить від способу отримання даних із клубної програми. Наявність API не гарантує потрібних повідомлень про події. Можна погодити регулярний обмін або передачу після зміни. Якщо працівник вручну завантажує файл, ручний крок залишається.
Чи можна підключити програму клубу до QuickBooks Online?
QuickBooks Online має Accounting API. Перед розробкою перевіряють дані клубної програми, а з бухгалтером погоджують документи, рахунки, валюту та правила повернень. Технічна можливість не підтверджує готового конектора; спочатку потрібні проба та звірка.
Скільки коштує розробка обміну LuckyFit і Finmap?
Фіксованої ціни немає. Artbrain може розглянути окремий модуль у межах кастомної розробки після безкоштовного розбору й перевірки даних обох систем. Письмову оцінку готуємо за погодженим обсягом. Послуги постачальників клієнт оплачує напряму, без нашої націнки.
