Практическое руководство по созданию мобильного приложения, которое фиксирует квитанции, извлекает данные через OCR, категоризирует расходы и экспортирует в бухгалтерские инструменты.
Прежде чем выбирать функции или экраны, конкретизируйте проблему, которую вы решаете. «Учет расходов» слишком широко; настоящая боль обычно в потерянных квитанциях, утомительном ручном вводе и медленных циклах возмещения.
Напишите одно‑предложение с формулировкой проблемы, которую можно проверять при каждом решении:
«Помочь людям зафиксировать квитанцию за секунды, автоматически превратить её в полный расход и отправить без гонки за недостающими деталями.»
Это удержит объём проекта в рамках и не даст превратить приложение в общий финансовый инструмент.
Большинство приложений для цифровых квитанций обслуживают несколько аудиторий:
Выберите сначала основного пользователя (часто сотрудники или фрилансеры), а опыт для финансовой команды спроектируйте как «слой проверки», а не как ядро рабочего процесса.
Сфокусируйте первую версию на небольшом наборе результатов:
Согласуйте несколько метрик, отражающих реальную ценность:
Когда цель, пользователи, задачи и метрики ясны, остальная часть разработки становится серией очевидных компромиссов, а не гаданием.
Прежде чем выбирать функции или экраны, опишите путь из конца в конец, который должно поддерживать приложение. Чёткий рабочий процесс предотвратит превращение «сканирования квитанций» в набор разрозненных инструментов.
Минимально необходимо проложить полный путь:
Для каждого шага указывайте, что видит пользователь, какие данные создаются и что должно происходить автоматически (например: подсчёт итогов, нормализация валюты, детекция налогов).
Решите основные точки входа — они формируют UI и допущения бэкенда:
Выберите один «дефолтный старт» для MVP, а остальные поддержите как вторичные пути.
Проясните, кто что может делать:
Продумайте правила передачи заранее (например: когда расход становится только для чтения, кто может переопределить, и как логируются изменения).
Задокументируйте реальные сложности: возвраты/рефанд, разделённые счета, мультивалюта, чаевые, отсутствующие квитанции и суточные/диеты. Даже если вы не автоматизируете их полностью в v1, рабочий поток должен содержать понятный путь, который не блокирует пользователей.
Хорошая модель данных упрощает всё остальное: быстрый поиск, меньше ручной правки и чистые экспорты в бухгалтерию. Ключ — отделить то, что пользователь захватил (оригинальный файл), от того, что приложение поняло (нормализованные поля для фильтров и отчётов).
Рассматривайте Receipt как доказательство (файл + результаты извлечения), а Expense как бизнес‑запись для возмещения, проверки по политике и отчётности.
Один расход может иметь одну квитанцию, несколько квитанций (разделённые платежи) или не иметь квитанции (ручной ввод) — моделируйте это гибко.
Планируйте поле capture_method, чтобы расширяться за пределы камерных сканов:
Это поле поможет отлаживать качество и настраивать OCR/парсер позже.
Как минимум, храните в Expense (даже если поле пришло из OCR): мерчант, дата, итог, налог, валюта, способ оплаты. Держите и сырой текст, и нормализованные значения (например, ISO‑коды валют, разобранные даты), чтобы правки можно было откатить и объяснить.
Также сохраняйте метаданные типа:
merchant_normalized (для консистентного поиска)transaction_last4 или токенизированная ссылка на карту (чтобы предотвращать дубликаты)timezone и locale (для корректного парсинга дат/налогов)Храните исходное изображение/PDF отдельно от извлечённых/нормализованных данных. Это позволяет повторно обрабатывать (лучший OCR позже) без потери оригинала.
Проектируйте поиск под реальные вопросы пользователей:
Индексируйте эти поля рано; это разница между «бесконечной прокруткой» и мгновенными ответами.
Включите правила хранения в схему, а не отложенно:
С этими элементами приложение сможет масштабироваться от персонального захвата расходов до корпоративного соответствия, не переписывая фундамент.
Начните с узкого, проверяемого описания проблемы (например: “зафиксировать квитанцию за секунды, автоматически создать расход, отправить без пропущенных деталей”). Затем выберите основного пользователя (сотрудники ИЛИ фрилансеры) и определите 2–4 измеримых метрика успеха, например:
Эти ограничения помогут избежать разрастания проекта до общего финансового инструмента.
Практический MVP-цикл: захват → извлечение → категоризация → экспорт/отправка.
В версии v1 приоритет:
Отложите детализацию строк, подкачки карточек, сложные политики и глубокие интеграции до стабильности основного цикла.
Постройте полный путь от «доказательства» до «подлежащего оплате»:
Для каждого шага укажите, что выполняется автоматически, что видит пользователь и какие данные создаются. Это предотвращает создание разрозненных инструментов, которые не доводят дело до возмещения.
Для MVP обычно выбирают один «дефолтный» вход (обычно камера), остальные добавляют как вторичные пути:
Выбор влияет на UX и бэкенд (например: предобработка изображений vs парсинг HTML/PDF). Сохраните источник в поле capture_method, чтобы анализировать качество и конверсию по каналам.
Моделируйте Receipt и Expense как отдельные, но связанные сущности:
Отношения гибкие: один расход может иметь несколько квитанций (разделённые платежи) или не иметь квитанций (ручной ввод). Храните и исходный OCR‑текст, и нормализованные поля, чтобы правки были объяснимыми и откатимыми.
Камера должна ощущаться как сканер:
Перед OCR выполните предобработку: выравнивание, коррекция перспективы, шумоподавление и нормализация контраста — это часто важнее, чем смена OCR‑движка.
Часто оптимален гибридный подход:
Всегда храните оценку уверенности по каждому полю (не только для квитанции) и показывайте экран быстрой проверки, выделяя только те поля, которые требуют внимания. Будьте открыты насчёт того, что триггерит выгрузку в облако, и дайте пользователю контроль.
Начните с правил, понятных пользователям, затем добавьте подсказки:
Добавьте настраиваемые поля: проект, центр затрат, клиент и теги политики, чтобы категоризация соответствовала реальным процессам.
Используйте комбинацию сигналов и не блокируйте инцидентально:
При обнаружении вероятного дубликата предложите обзор «рядом‑рядом» и опцию «Сохранить оба». Логируйте подозрительные изменения (например, правка суммы после OCR) в аудите для дальнейшей проверки.
Сделайте офлайн‑первым поведение по умолчанию:
Показывайте состояния вроде «Сохранено локально • Синхронизируется» и используйте уведомления для важных событий (OCR готов, отклонено, утверждено). Это делает приложение надёжным при плохой связи.