Розробка мобільного застосунку для передачі показань лічильників ЖКГ
Уявіть: мешканець відкриває застосунок, бачить список лічильників, вводить показання та надсилає. Здається, що все просто. Але на ділі кожна помилка валідації, кожен збій OCR на блискучому циферблаті перетворює рутинне завдання на головний біль для керівних компаній. Ми вирішуємо такі проблеми вже 5 років: спроєктували та запустили 12 застосунків для передачі показань з інтеграцією в 1С, РКЦ та Інфократ. Наш досвід — 50+ проєктів у сфері ЖКГ.
Як працює основна механіка та де вона ламається?
Мешканець заходить у застосунок, бачить список лічильників за своїм особовим рахунком (вода холодна, гаряча, електрика, газ), вводить показання та надсилає. Це — 80% випадків. Решта 20% створюють 80% проблем. Розберемо три ключові вузли.
Валідація показань
Показання не можуть бути меншими за попередні — крім випадку заміни лічильника. Якщо різниця між поточними та попередніми перевищує порогове значення (наприклад, 50 кубів води за місяць — підозріло), система має запитати підтвердження, а не мовчки прийняти. Пороги — налаштовувані параметри в адміністративній панелі, не захардкоджені константи. Це дозволяє керівній компанії гнучко змінювати ліміти без оновлення застосунку.
Дедлайн передачі
Більшість КК приймають показання з 15 по 25 число. За межами цього вікна форма має бути заблокована зі зрозумілим повідомленням — не просто «помилка», а «Показання приймаються з 15 по 25 число. Наступне вікно відкриється через X днів». Реалізується через серверний конфіг, не через логіку в застосунку.
OCR-введення через камеру
ML Kit Text Recognition (Android) / Vision Framework (iOS) для розпізнавання цифр з екрана лічильника. У теорії зручно — на практиці розпізнавання роликового лічильника з відблисками працює в 60-70% випадків. Тому OCR — допоміжний інструмент, не заміна ручному введенню. Результат розпізнавання заповнює поле, мешканець підтверджує або виправляє.
| Параметр | Ручне введення | OCR |
|---|---|---|
| Швидкість введення | 10–15 секунд | 5–7 секунд |
| Точність на чистих цифрах | 100% | 95% |
| Точність на блискучих циферблатах | 100% | 60–70% |
| Зручність для пенсіонерів | Середня | Висока (кнопка «сфотографувати») |
OCR працює в 2 рази швидше за ручне введення, але точність розпізнавання рукописних цифр на 15% нижча — тому ми робимо OCR допоміжним, а не основним методом. При цьому 80% застосунків відмовляють в апруві App Store через некоректне використання камери — ми врахували це в архітектурі (див. Guidelines 5.1 — Apple Developer).
Для тестування OCR на реальних даних запитайте демо-доступ.
Як уникнути помилок при валідації показань?
Найчастіша проблема — ігнорування неочевидних кейсів: заміна лічильника, аварійне збільшення витрати (прорив труби), передача нульових показань при відсутності проживання. У нашому рішенні кожен виняток обробляється окремим правилом: якщо різниця між показаннями від'ємна — запитуємо підтвердження з прикріпленням фото; якщо перевищує поріг — блокуємо відправлення до дзвінка оператору. Усі правила налаштовуються в адмін-панелі.
Як відбувається інтеграція з білінгом?
Найважливіша частина. Дані мають потрапити в систему обліку керівної компанії — 1С:Бухгалтерія, РКЦ, Інфократ або іншу. Способи: REST API (якщо білінг підтримує), файловий обмін XML/CSV за розкладом, прямий запис у базу (з дозволу вендора — рідко, але буває). На стороні нашого бекенду (Laravel + PostgreSQL) зберігається історія всіх переданих показань з timestamp, device ID та IP — для розбору суперечок про те, чи були показання передані та коли.
Порівняння способів інтеграції:
| Спосіб | Швидкість налаштування | Гнучкість | Надійність |
|---|---|---|---|
| REST API | 1–2 тижні | Висока | Висока |
| Файловий обмін (XML/CSV) | 2–3 дні | Середня | Середня (залежить від розкладу) |
| Прямий запис у БД | 1–2 дні | Висока | Низька (ризик блокування вендором) |
Чому інтеграція з білінгом — найвужче місце?
Тому що кожна КК використовує свою систему: 1С, РКЦ, Інфократ, Альфа-Діалог, Міські портали. Універсального API немає. Ми розробляємо адаптер під конкретний білінг на основі його документації. На практиці 30% часу йде на узгодження форматів даних та тестування прийому на стороні замовника. Щоб прискорити процес, ми надаємо специфікацію API та допомагаємо налаштувати прийом даних. Гарантуємо, що після здачі дані передаватимуться коректно.
Як налаштувати інтеграцію з білінгом: покрокова інструкція
- Визначте, який білінг використовуєте (1С, РКЦ, Інфократ тощо).
- Надайте нам документацію API або опис файлового обміну.
- Ми розробляємо адаптер та тестовий стенд.
- Проводимо спільне тестування з вашим відділом інформаційних систем.
- Розгортаємо рішення на продуктивному контурі.
- Навчаємо операторів роботі з новим інтерфейсом.
Процес роботи
- Аналітика — вивчаємо поточний білінг, схеми даних, бізнес-процеси КК.
- Проєктування — дизайн екранів (Figma), опис API, прототип валідації.
- Розробка — Flutter + Dart, Laravel 10 API, PostgreSQL.
- Тестування — на 10+ пристроях (iOS та Android), включаючи моделі з різними версіями ОС.
- Інтеграція — налаштування обміну з білінгом, завантаження тестових даних.
- Запуск — публікація в App Store та Google Play, налаштування push-сповіщень (FCM), навчання операторів.
- Підтримка — гарантійне обслуговування 3 місяці.
Що входить у результат
- Вихідний код застосунку (Flutter) з коментарями.
- Документація API (Swagger/OpenAPI).
- Адміністративна панель для налаштування порогів та вікон передачі.
- Інструкція для операторів (3–5 сторінок).
- Сертифікати підпису (iOS provisioning profile, Android keystore).
- Доступи до App Store Connect та Google Play Console.
- Навчання співробітників (відеодзвінок 1–2 години).
Терміни та вартість
Терміни — від 5 до 8 тижнів залежно від складності інтеграції. Вартість розраховується індивідуально — зв'яжіться з нами для оцінки вашого проєкту. Ми надамо детальний кошторис протягом 2 робочих днів.
Отримайте консультацію з інтеграції білінгу — наші інженери проаналізують вашу поточну систему та запропонують оптимальне рішення.