Александр
|
6 декабря 2015 20:48
|
Добрый день!
К сожалению, у меня банк присылает уведомления по карте с описанием списания/прихода в нескольких строках.
Возможно как-то настроить импорт, чтобы он смог распарсить такие письма?
Если нет, то планируете ли вы реализацию данного функционала?
|
|
|
Admin
|
7 декабря 2015 10:35
|
Здравствуйте.
К сожалению нет, многострочных вариантов может быть очень много, под все не подстроишься.
Возможно некоторые почтовые программы позволяют делать преобразования текстов писем, с последующей пересылкой. Можно покопать в эту сторону.
|
|
|
Александр
|
2 января 2016 13:10
|
Здравствуйте!
Смотрите, мой банк транзакции по карте отсылает по смс и дублирует их на е-майл, т.е. одно письмо, одна транзакция. Там все тоже самое, что и в смс, разве что на разных строках. Вполне можно искать шаблоны в каждой строке, можно ограничить количество обрабатываемых строк, если необходимо.
|
|
|
Сергей
|
24 марта 2016 15:36
|
Добрый день. Была проблема с ВТБ-шными рассылками. Руками удалял перевод строки и отправлял на парсер. Надоело, написал программку под windows. Сейчас с помощью нее обрабатываю 4 банка. Программа делает следующее: во вставленном из буфера или перетащенном тексте удаляет символы конца строки, табуляции, заменяет слова сегодня, вчера на даты, преобразует даты вида 24.03 к виду 24.03.16 (сделано для Сбербанка), удаляет из сообщения указанные слова (типа Уважаемый Иван Петрович), позволяет вставлять в начало сообщения некий текст (для лучшего распознования парсером) и отправляет преобразованный текст парсеру. Если интересно, могу поделиться
|
|
|
Сергей
|
5 октября 2016 20:05
|
Добрый день. Можно на данный момент как-то сделать, чтобы при отправке списка расходов с e-mail расходы группировались или группировать расходы потом (после обработки) в web интерфейсе?
|
|
|
Admin
|
5 октября 2016 21:35
|
Здравствуйте.
На данный момент нет. Это уже задача скорее на использование нашего API, чтобы автоматизировать процесс на программном уровне. Вы можете сами это сделать или найти разработчика.
|
|
|
Сергей
|
6 октября 2016 09:00
|
Спасибо за предложение. Думаю можно попробовать написать ("попробовать", потому что не знаю как работает ваше API).
Алгоритм вижу следующий:
В первую строку письма заносится ключевое слово, например "Группировать" и тогда все записи из этого письма группируются.
Если ключевого слова нет в первой строке, то все идет как обычно.
Думал сделать через Отчеты-Действия со списком и дальше сделать "Объединение", но там может попасть много лишних записей.
Чтобы их исключить, надо в отчетах делать возможность ввода Даты плюс Времени.
|
|
|
Admin
|
6 октября 2016 15:20
|
Действовать нужно не через вставку в email, их обработчик не связан с API.
В API есть метод для сохранения операций, setRecordList(), в который передаётся список сохраняемых операций, у каждой из которых может быть задан идентификатор группы (некое уникальное число), который и будет означать создание группы.
При этом вы сами ответственны за формирование списка операций. Вспомогательно можно использовать API метод parseTextData(), который на вход принимает текст (ваш email) и на выходе выдаёт структуру из распознанных данных, на основе которых можно формировать операции расходов, для setRecordList.
|
|
|
Сергей
|
6 октября 2016 15:32
|
В первом приближении понятно, буду пробовать
|
|
|
Сергей
|
10 октября 2016 09:09
|
Добрый день. Метод getRecordList() возвращает budget_object_id. Каким методом можно получить название budget_object?
|
|
|
Admin
|
10 октября 2016 10:24
|
Это id категории расходов или источника доходов, список которых получается через getCategoryList и getSourceList соответственно.
Пишите лучше подобные вопросы в обратную связь.
|
|
|
Владимир Ситников
|
7 января 2017 00:35
|
Сделал схему обработки email.
1) Банк шлёт email'ы следующего вида:
Уважаемый клиент,
Покупка на сумму 29817.00 RUB была произведена по Вашему счету **8151
Торговая точка: SANTEHNIKA-ONLI
Дата операции: 19/12/2016
Доступный баланс: ..... RUB
Сумма зарезервирована на счете Вашей дебетовой карты. Факт....
2) Это сообщение я пересылаю на свой обработчик в google app engine. Т.е. это просто перенаправление email'а на info@myapp.appspotmail.com
3) Там простейшая программа на python собирает "сумму, операцию, и номер счёта" в одну строку (чтобы дребеденьги смогли обработать) и отправляет на обработку в ДД.
Собственно, вот весь код: https://github.com/vlsi/citibank-gae-drebedengi/blob/master/handle_incoming_email.py
Запустить приложение в app engine оказалось несложно, всё это хозяйство укладывается в бесплатные рамки, и работает весьма быстро.
4) В ДребеДенгах кучка правил. В частности, для текущего и сберегательного счёта приходится держать дубли правил, отличающиеся только тем, что они срабатывают на разные номера счёта
Расходов у меня не много, и, полагаю, всё это будет с лихвой укладываться в бесплатные ограничения Google App Engine.
Возможно, следующий подход к снаряду будет уже с использованием ДД API, чтобы вместо ДД правил использовать свои правила.
Бочка дёгтя:
1) Анализатор ДребеДенег выдаёт весьма скудную информацию. Вообще невозможно понять какие данные он получил, какие отбросил, какие правила применились, а какие нет.
app engine приложение я могу тестировать прямо на своём компьютере. Можно запустить локальную копию, и посылать в неё прошлые банковские письма. А вот с правилами ДД полный облом. Тестировать приходится на живую, и непонятно как анализировать ошибки.
При этом, у app engine есть ограничение "100 сообщений в день". Для боевого режима вполне достаточно, а вот для отладки этот лимит запросто улетит.
2) Почему-то анализатор откусывает информацию.
Я отправляю: "Тип: зачисление; Сумма: 100.00 RUB; Счёт: 8151; Категория: Перевод на свои счета"
В ДД (когда поставил галочку "сохранять полученную строку в комментарий"): "Тип: зачисление; Сумма: 100.00 RUB; Счёт: 8151; Категория: Перевод на свои" (слово "счета" кто-то откусил!)
Фиг знает почему так, но пока я временно в правилах указал "Перевод на свои" без слова "счета".
3) Тяжеловато тестировать правила. Было бы хорошо в UI иметь возможность указать строку, а она сказала какие правила сработали, какие не сработали и почему.
|
|
|
Admin
|
7 января 2017 16:32
|
Владимир, спасибо, интересная информация.
По поводу тестирования - как минимум можно загружать файл со строками-тратами в разделе "Импорт данных", и всё видеть на этапе предварительного просмотра.
Какое правило сработало там не отобразится, но никто не мешает для тестов, например, для каждого правила добавлять уникальный тег (на любое слово), таким образом их можно идентифицировать.
|
|
|
Владимир Ситников
|
10 января 2017 21:04
|
Владимир Пишет: Почему-то анализатор откусывает информацию
Оказалось, анализатор правильный, а это при отправке письма Google добавлял вредительские переводы строк.
Стал отправлять информацию во вложении (да, знаю что так рекомендуется, но я поленился, а там не говорилось чем может грозить) -- заработало.
|
|
|
Сергей
|
11 апреля 2020 11:24
|
Добрый день!
Перешел недавно на ios спустя n лет на андроиде, где была настроена обработка смс.
И в плане автоматической обработки откатился как в каменный век (
высмотрел возможность автоматизировать через e-mail. Но там смотрю тоже тот еще квест.
Смотрю, еще в 2017 Владимир Ситников предлагал какой-то прикольный лайфках, но для простого смертного он сложный. Хотя запрос я считаю очень логичным.
Коллектив дребеденег, не могли бы вы позаботиться о своих клиентах и один раз засесть и придумать инструмент по обработке e-mail от банков? ну, какую-нибудь программк написать, которая подхватывала бы все, что надо, отправляло, куда надо и тд. Да, у всех банков свой формат сообщений и возможно одним скриптом не получилось бы отделаться, но может за платную подписку могли бы помогать людям ее настроить?
Это не претензия, а просто просьба к вам - как-то позаботиться о лояльных к вам клиентах )
Просто честно, я страдаю с копированием смс после того, как несколько лет оно делалось на автомате.
|
|
|
Admin
|
11 апреля 2020 11:34
|
Подумаем, но уже думали и ничего пока не придумали.
Более простые варианты возможны (например, без кода), но не безопасны и решиться на это мы пока не можем.
|
|
|