Авто-обработка транзакций c карт физ. лиц для Финолога: порадуйте вашего бухгалтера

Чтобы упростить и ускорить процесс загрузки банковских транзакций в Финолог, мы разработали решение, которое сводит ручную обработку данных к минимуму, исключив ошибки и возможное дублирование данных.

Эта статья с инструкцией о том, как самостоятельно настроить автоматизацию при помощи конструктора сценариев Zapier и Google Таблиц. (В предыдущей статье описали как этот простой процесс выгрузки транзакций в Финолог выглядит глазами бухгалтера)

Вот как это упростило жизнь.

Реализация сценария проходит в два этапа:

• Первый — анализ банковской выгрузки с приведением данных к единому стандарту; 

• Второй — отправка данных в сервис учета (Финолог) с подтверждением корректности результата автозагрузки

  Кстати, настройка описанного процесса не требует глубоких навыков обращения с программным интерфейсом.

Для интеграции достаточно выбрать приложение из каталога и задать нужное действие — система автоматически «подтянет» нужные данные.  

Зачем это нужно

Учетный сервис Финолог — это удобный программный комплекс, который удовлетворяет потребности нашей компании в организации финансовых данных. Но с ним есть нюанс: необходимость в ручной обработке данных с карт физических лиц о транзакциях перед загрузкой в сервис. Мы же этот процесс автоматизировали.

Этап 1: Обработка данных перед загрузкой

Общая схема автоматизации по приведению данных к нужному виду в интерфейсе Zapier выглядит так: 

Остановимся подробнее на механике действий в сценарии.

1) New or Updated Spreadsheet Row (Google Sheets).

По колонке «дата операции» создаем триггер, запускающий автоматизацию. Эта колонка выбрана не случайно — это первая колонка в стандартном файле при выгрузке отчета из Тинька. (Подробнее разобрали в прошлой статье)

2) Filter conditions

Настройка автоматических реакций как на новые, так и на измененные данные. Алгоритм учитывает оба варианта, позволяя избежать удаления и повторного внесения информации после правок.

3) Transform date.

Определяем формат поступающих данных, сравниваем с целевым, конвертируем (в нашем примере нужно поменять только дату).

4) Split value.

Исключение лишних цифр, которые могут создавать ошибки в расчетах (в нашем случае, это ноли/копейки).

5) Value greater.

Использование формул Google Sheets позволяет задать одно из следующих условий

если транзакция доходная → получаем значение 1;

если расходная → получаем 0. 

Таким образом, система автоматически определяет категорию транзакции

6) Lookup in or out transaction.

Значения 1 и 0 преобразуются в понятные: In (доход) и Out (расход).

7) Lookup (определение) номера счет в Финологе.

Получаем последние цифры карты и сопоставляем с записями сервиса учета для корректной разбивки (в нашем случае — это три карты Тинькофф, поэтому счета тоже три).

8) Replace, to.

Замена форматов чисел на корректные разделители (,, .).

9) Итоговый вывод данных в файл Main (Google Sheets).

Преобразованные данные автоматически заполняют нужные столбцы в таблице Main.

Этап 2: Отправка данных в Финолог с проверкой на дубликаты или ошибки

Схема второго этапа:

Часть сцценария здесь повторяется, разберем самое сложное:

2) Проверка на приход или расход.

Задаем параметры, которые позже будем сверять с отправленными в Финолог.

3) Преобразуем данные даты (format date/time)

Убираем часы, минуты и секунды, так как Финолог их не учитывает. На этом этапе возможна ошибка: если в один день произойдут одинаковые по сумме транзакции, система определит их как дубль.

В этом случае нужно просто изменить дату транзакции. Для учета это не критично — дебет с кредитом все равно сойдется, так как мы считаем в рамках месяца, а не дня.

4) Переменные из сторадж

По сути, это псевдотаблица внутри Zapier. К ней мы обращаемся с запросом на поиск строки в столбце A, где записан finolog_id. Действие показывает нам значение этого finolog_id.

5) Поиск транзакции в Финологе.

Перед созданием новой транзакции отправляем GET-запрос в Финолог, чтобы проверить, не существует ли уже такой записи. В URL указывается, какую именно транзакцию ищем.

8) Создание транзакции (ответ Финолога):

• если транзакция найдена → система сообщает об этом;

• если не найдена → переходим к созданию новой.

12) Запись ошибки в таблицу.

При обнаружении проблемы (например, дубля записи), система автоматически генерирует сообщение об ошибке, помещая в триггерную строку.

Итог

Самым ценным следствием доработки, стала благодарность нашего бухгалтера, у которой вместо дней и часов ручного поиска ошибок в отчетах в транзакциях, приведение данных к стандартному виду и проверка на дубли, теперь занимает всего несколько минут. 

К очевидным преимуществам этого решения можно также отнести универсальность: его легко применить к аналогичному сервису бухгалтерского учета, сделав обработку транзакций быстрее, проще и точнее. Окупится такая автоматизация всего за пару месяцев, а вот спокойствие тех, кто отвечает за отсутствие ошибок в финансовых документах — бесценно!

Хотите что-то подобное сделать для своего бизнеса? Оставьте заявку на разработку нашем сайте, мы решим, как вам помочь.