Сообщество
Логин
Пароль
Забыли пароль?     Регистрация
Ещё проектики
Рабочее время
Минималистичный счётчик рабочего времени онлайн
Общение / Веб версия / Автозаполнение расходов из СМСки по банковской кар ...

Автозаполнение расходов из смски по банковской карточке

dmpro
14 октября 2013 09:12
Везде где можно плачу карточкой сбербанка. Мне приходит СМС на телефон с номера 900. А нельзя ли, что бы дребеденьги на телефоне "читали" эти СМСки и разносили расход. Категорию можно будет подставить позже. А если постоянно пользоваться карточкой в одних и тех же местах, то по содержанию СМСки можно будет в дальнейшем и автоматом назначать категорию расхода.
Admin
 
14 октября 2013 09:34
Добрый день.
Такая идея обдумывается. В будущих версиях сделаем.
Надежда
14 октября 2013 10:53
А еще стоит сделать блок по квартплате. Трудно собрать в кучу если платить не регулярно. Следуеткуда то занести квитанции как задолженность и оплату по месяцам. Сейчас приходится еще контролировать и вести отдельный файл в Екселе.
Admin
 
14 октября 2013 20:32
Надежда Пишет:
А еще стоит сделать блок по квартплате
Здравствуйте,
Для этой цели вы можете воспользоваться системой планирования бюджета или "накоминалкой".
ApTeM
15 октября 2013 07:42
вот меня тоже интересует как организовать в плане бюджета коммуналку, если:
у меня уже есть задолженность - хорошо я её кинул в начальные долги.
Но вдруг я один месяц не оплачу, что остаётся:
1. увеличить первоначальный долг
2. только ручками перепланировать следующий месяц с учетом неоплаты коммуналки в текущем месяце.
Например, в плане расходов 300 по какой-либо категории, фактически по этой категории произведен расход в месяй 200, а так чтобы на следующий месяц было авто запланировано остаток (300-200) плюс плановая трата на следующий месяц 300+100, т.е. уже 400
ApTeM
15 октября 2013 07:43
ps первый вариант не устраивает
ApTeM
15 октября 2013 08:16
разобрался: как вариант правильно увеличить задолженность если планируемая сумма не была оплачена, то просто внести расход из долгового места - сумма долга увеличится,
а вот если бы как-нибудь по второму варианту придумать?
Admin
 
15 октября 2013 09:58
Artem Пишет:
а вот если бы как-нибудь по второму варианту придумать?
А чем плох вариант вручную внести изменения в лимит на следующий месяц?
ApTeM
15 октября 2013 14:32
согласен, впринципе тут я уже нагородил, уже уж через чур решил усложнить,
но тогда хотелось бы (ни раз уже на форуме обсуждалось), чтобы в плане расходов помимо колонки "Ежедневно" была колонка "Осталось", и наглядно было бы и можно просто в клик перейти на следующий месяц и к сумме прибавить то что "осталось" в этом месяце.

Действительно, ведь наверное такую колонку добавить не сложно.
Да и вообще (так же обсуждалась) от колонки "Ежедневно осталось потратить" не для всех категорий имеет смысл (та же квартплата). Может добавить к категориям признак необходимости учитывать "Ежедневно осталось потратить" и выводить для таких эту колонку, а для других категорий колонку "всего осталось потратить". Это вообще-то не сложно должно быть в одной колонке показывать, а что показывать, в зависимости от признака. Так же цветом выделить. Но вот совсем просто - обе колонки вывести для начала, каждый пользователь по нужной ему категории будет просматривать нужную ему колонку. Типа как "контроль расходов" у вас реализован, но при планировании бюджета было бы удобнее и нагляднее. Кстати, в планировании кто-нибудь использует колонку "комментарий"?
ApTeM
14 февраля 2015 15:39
вот смотрю тема затерлась коммуналкой, а ведь полтора года назад был вопрос про номер 900, актуально на сегодня? Сам плачу картой почти везде и всюду
Admin
 
14 февраля 2015 15:45
Artem Пишет:
а ведь полтора года назад был вопрос про номер 900, актуально на сегодня?
Актуально, скоро уже будем делать.
NO NAME
15 февраля 2015 11:39
Admin Пишет:
Artem Пишет:а ведь полтора года назад был вопрос про номер 900, актуально на сегодня?Актуально, скоро уже будем делать.
Скоро уже будете включать функционал на сервисе или скоро приступите к разработке? Сам весьма скептически отношусь к данной функции. Судя по опыту, полученному при работе с сервисом- конкрунтом (уже не помню названия), особых восторгов я от этой функции не испытывал совершенно, постоянно какой то бардак с ведением расходов с карты был.
Admin
 
15 февраля 2015 15:12
Денис Пишет:
или скоро приступите к разработке?
Скоро приступим.
Работать будет по принципу автозаполнения полей формы ввода, либо с созданием "черновых" трат, которые пользователю надо будет подтверждать/корректировать.
dmpro
18 февраля 2015 12:19
Денис Пишет:
восторгов я от этой функции не испытывал совершенно,
А у меня наоборот, я вижу все расходы по карточке в банке, пытаюсь все "скрыжить" в дребеденьги и в итоге бросаю это дело. В сбербанк онлайн очень наглядно все показано, куда, кому, статьи затрат привязаны к получателю. Сходил в Магнит - затрата "Продукты"
Если такая функция вернется, наверно попробую опять вернуться в этот сервис.
kirillov.s.v
21 февраля 2015 01:03
Уважаемые разработчики! Жду не дождусь реализации этой функции, писал-общался с вами на эту тему года два назад еще.
Большая просьба - дабы не испортить идею на корню, посмотрите, пожалуйста, вначале, как это сделано у конкурентов. Я имею ввиду Дзенмани. Я года три ими пользовался и всегда люто ненавидел разработчика, высокомерного и высокопарного небрежного лентяя, от чего в итоге и сбежал в Дребеденьги. Но, справедливости ради, замечу, что в те времена, когда распознавание у них работало - было крайне удобно и никакого бардака не было. И это была там для меня главная функция, из-за которой "ежики плакали, кололись, но продолжали есть кактус". Я имею ввиду себя. Потому что все остальное там плохо, неудобно и некрасиво.

Самые важные моменты, которые по моему мнению, должны быть и в Дребеденьгах:
1. Пользователь сам настраивает привязку уведомлений к своим категориям затрат по различным полям уведомления (получатель, номер счета, комментарий, текст). Задаются текстовые маски, а не просто целиком содержимое поля.
2. Пользователь сам настраивает что делать с таким уведомлением, которое удовлетворило данному правилу - добавить/не добавлять транзакцию, выставить теги, создать перемещение между счетами, выставить плательщика/получателя.

Кстати, поля "Получатель/Плательщик" при вводе операций реально не хватает в Дребеденьгах, это вполне себе четко оформленный атрибут, присущий каждой операции расхода/дохода. И тегами это не вполне покрывается. При обработке банковских уведомлений вы обязательно столкнетесь с этим вопросом, так как в реквизитах этих уведомлений всегда есть поле с наименованием получателя платежа, единственное поле, по которому можно будет делать привязку к категориям. Если такого же поля не будет в Дребеденьгах, будет тяжко пользователю, так как придется вводить уйму тегов - по одному для каждого магазина, и даже для каждого терминала в одном магазине.

3. Система обрабатывает не только СМС, а и e-mail от банков. СМС - в мобильной версии, почту - на сайте. Почтовые уведомления от банков кому-то будет использовать удобнее, так как они обычно более детальны и на русском языке, а не на транслите, как СМС некоторых банков.
4. Никаких дополнительных действий от пользователя не требуется после того как правила настроены, транзакции учитываются в системе полностью автоматически без подтверждений. Если что-то не так - всегда можно отредактировать позже при необходимости.
5. Если уведомление не удалось корректно распознать - система сообщает пользователю об этом отдельно (отдельная вкладка в мобильном приложении и редирект имейлов в пометкой в заголовке о нераспознанном уведомлении).

Самая большая проблема распознавания заключается в том, что банки время от времени любят менять формат сообщений, и парсер начинает спотыкаться на каждом, пока разработчик его не адаптирует. Поддержка Дзенмани отличается крайней недружелюбностью к пользователям, и несмотря на многочисленные вопли оных об очередном сломавшемся распознавании, починки парсера приходилось ждать месяцами! В последнем случае срок ожидания достиг аж полутора лет, это просто немыслимо, чтобы так работала поддержка. Я выдержал полгода и послал их куда подальше. И хоть сейчас там вроде бы все и работает, ни за что к ним не вернусь, так как доверия нет, могут снова кинуть в любой момент. Диаметрально противоположная ситуация в Дребеденьгах - живая и адекватная поддержка, и даже несмотря на полную бесплатность Дзенманей, я купил в Дребеденьгах премимум подписку еще до того, как данная функция здесь будет реализована, так как полностью доверяю этому качественному сервису, и уверен, что Дребеденьги будут следить за актуальностью своего будущего парсера уведомлений и незамедлительно его править вслед за банками.
Спасибо за вниание, что-то я разошелся :)
Admin
 
21 февраля 2015 08:58
kirillov.s.v Пишет:
Самые важные моменты, которые по моему мнению, должны быть и в Дребеденьгах
Добрый день.
Парсер будет развиваться постепенно, до описанного вами варианта, конечно, ещё далеко. Для начала всё будет работать с подтверждением от пользователя (пришла СМС, автоматически заполнилась форма, пользователь скорректировал, сохранил). На основе этого мы будем собирать статистику и оттачивать работу парсера.

1. Со временем будет
2. Не совсем понятно о чём речь. Если можно приведите несколько примеров СМС и нес-ко таких сценариев настройки.
3. Будет
4. Под вопросом, пока сомнительно. Пользователь же как минимум должен видеть (и потому проверить) что такие-то операции были внесены автоматически. Вероятность ошибки всегда есть.
5. Пока будет решаться 4-м пунктом.
kirillov.s.v
21 февраля 2015 14:12
По второму пункту.
Для каждого правила есть две группы настроек.
Первая - это фильтр, то есть парсинг сообщения и принятие решения - удовлетворяет данное сообщение этому правилу или нет.
Вторая - действия, то есть если сообщение удовлетворило данному правилу, то что с ним делать.
Собственно, ничего нового, точно также как работают фильтры во всех почтовых сервисах.

Среди действий пользователь может задать несколько пунктов:
1. Добавлять или не добавлять транзакцию. Зачем это конкретно надо сказать трудно, так как бывает множество неоднозначных ситуаций. Среди банковских уведомлений присутствуют не только уведомления о доходах или расходах. Могут быть уведомления об исполнении запланированных операций, к примеру, а их обрабатывать нужно будет иначе, так как например у ВТБ24 такие уведомления не содержат сумму, и получить её парсером не удастся. Но это может быть настроено как раз в правиле (к слову, именно этой тонкости Дзенмани как раз и не делают, хотя их многократно просили, их вообще много о чем просили, но...).
2. Выставить теги. Ну тут все понятно, думаю.
3. Выставить получателя/плательщика. В Дребеденьгах такого поля пока нет, но если оно будет, то это нужно для более читабельного представления имени получателя, так как в уведомлениях в этом поле фигурируют самые разнообразно предсталенные сведения, не только название организации, но еще и какие-то служебные номера, возможно номера терминалов. Так, к примеру, магазинов одной сети много, в каждом много терминалов, с каждого терминала уведомление содержит в поле получателя немного отличающийся текст. И он отличается не только номерами терминалов. Например, Максидом из разных магазинов присылает уведомления с названиями MAXIDOM, MAKSIDOM и т.п. Что конкретный наладчик термианала в конкретном месте вобьет, то и будет. А по сути это один и тот же магазин.
4. Какой тип операции создать. Тут все просто. Уведомления от магазинов - это расходные операции. Уведомления от банкоматов - это переводы средств между счетами (с карточного счета в наличные). Уведомления об увеличении баланса - это доходы (зарплата). Хотя иногда увеличение баланса появляется и в иных случаях, например при переводе средств со своего внутреннего счета на карту. Тут уже мог бы помочь фильтр по датам, зарплата часто в одни и те же числа месяца выплачивается. Так вот все эти типы операций может определить только сам пользователь соответствующей настройкой правила, автоматизировать этот процесс вряд ли получится качественно. Но может быть вам это и удастся.

Вообще в Дзенманях изначально не было правил для автоматической обработки. И было все плохо, был бардак. Они не смогли сделать четкую автоматику. И тогда пользователи восстали, и я был во главе их числа, и стали требовать ввести правила обработки, настраиваемые пользователем. И стало все хорошо. Да, вначале этому нужно уделить много внимания, чтобы настроить все правила. Но зато потом жить хорошо и приятно.

Ну вот, в общих чертах как то так.
Admin
 
21 февраля 2015 14:51
Спасибо за описание, примем к сведению.
Admin
 
16 марта 2015 16:54
Admin Пишет:
Если такого же поля не будет в Дребеденьгах, будет тяжко пользователю, так как придется вводить уйму тегов
Кстати, не понятно. Тегов придётся заводить ровно столько же, сколько бы пришлось заводить получателей. Разве нет?
kirillov.s.v
16 марта 2015 22:36
Admin Пишет:
Кстати, не понятно. Тегов придётся заводить ровно столько же, сколько бы пришлось заводить получателей. Разве нет?
Вот именно! Об этом и речь! Да, ровно столько же - и это будет очень много!
На каждого получателя заводить свой тег неразумно и не нужно.
А при наличии такого поля в Дребеденьгах получателей заводить не пришлось бы вовсе, это поле просто бы само заполнялось из уведомлений. Не нужно получателей иметь в виде отдельной базы данных, достаточно чтобы это был аналог поля Комментарий, просто текстовое поле с заголовком Получатель, по которому можно фильтровать отдельно от других данных, и которое заполняется автоматом из уведомлений с возможностью ручной правки. То есть, в терминологии БД, не нужна отдельная таблица для получателей, достаточно в общей таблице операций иметь текстовое поле Получатель. Каждого получателя не нужно рассматривать как отдельную сущность, достаточно их рассматривать просто как текстовый атрибут каждой конкретной операции.

И было бы правильно не просто копировать содержимое этого поля, а иметь возможность модифицировать его по фильтру.
К примеру, вот какие варианты поля Получатель приходят в уведомлениях от разных заправок одного бренда:
SHELL NEFT NOVOROSSIYSKA
SHELL NEFT DACHNOE 910
SHELL NEFT KULTURY 945
SHELL NEFT TORZHKOVSKAYA
SHELL NEFT MISTOLOVO
SHELL NEFT PRIMORSKAYA 1
В системе же достаточно просто видеть - SHELL, без ненужных уточнений.
А кому-то может и бренд не важен, и он захочет все заправки разных брендов обозвать одним именем получателя - Автозаправка.

Тогда в общем случае касательно поля Получатель было бы удобно задавать правила вида:
если поле "получатель"
содержит текст aaa или
содержит текст bbb или
содержит текст ccc или...
то операции присвоить тип расходная
задать категорию ddd
и назначить теги eee, fff, ggg.
Admin
 
17 марта 2015 09:16
kirillov.s.v Пишет:
А при наличии такого поля в Дребеденьгах получателей заводить не пришлось бы вовсе, это поле просто бы само заполнялось из уведомлений.
Нет никакой разницы, какое поле заполнять автоматически - тег или получатель.

"..Каждого получателя не нужно рассматривать как отдельную сущность, достаточно их рассматривать просто как текстовый атрибут каждой конкретной операции.." - это не хорошо, потому что сулит много проблем. Давно пройдено.
kirillov.s.v
17 марта 2015 09:25
Admin Пишет:
Нет никакой разницы, какое поле заполнять автоматически - тег или получатель.
Это и ежу понятно. Вы не на том акцентировались. Основная идея в том, чтобы отделить мух от котлет. Получатель - самодостаточный обособленный тип данных, и мешать его в общую кучу разносмысловых тегов плохо. Очень плохо. Неюзабельно. Вот и всё. Это просто изначально должно быть отделено, ну а как именно реализовать - решать вам.
kirillov.s.v
17 марта 2015 09:26
Admin Пишет:
это не хорошо, потому что сулит много проблем. Давно пройдено.
С этим спорить не буду, опыта проектирования подобных БД нет.
dmpro
17 марта 2015 09:47
С точки зрения программирования текстовое поле не хорошо. Слишком высокая неопределенность содержания не позволит обрабатывать и классифицировать суть данных. Обычно для классификации в нормализованной БД таблице с описанием сущности достаточно разметить реквизит, классифицирующий содержание.
В сбербанк онлайн молодцы. Сделали закладку финансы. Теперь там все платежи по карте в виде круговой диаграммы: Еда, Связь, Комуналка, Транспорт. Благодаря этому учитывать расходы в дребеденьги уже не нужно. Просто достаточно одной суммой отразить списание в затраты, а конкретика есть там. Минимум платежей наличными не мешает видеть картину маслом.
Admin
 
17 марта 2015 09:56
kirillov.s.v Пишет:
Получатель - самодостаточный обособленный тип данных, и мешать его в общую кучу разносмысловых тегов плохо.
Спорно. Получатель - это частный случай тегов, т.е. подмножество. Наряду с местами, событиями и т.п. Заводить для каждой такой сущности своё поле - усложнение интерфейса и избыточность.

Для упорядочивания общего списка тегов он представлен в виде дерева, где каждая ветка может означать свою логическую под-сущность.

А для реализации каких-то особенностей каждой из подсущностей (напр. описание получателей), логичнее будет ввести атрибуты тегов. Об этом думаем.
kirillov.s.v
17 марта 2015 14:58
Ну, отстаивать с пеной у рта свою позицию не стану. Да, в теории Вы правы. Как я уже говорил, тегами можно описать вообще всё, и без категорий обойтись можно. Вся соль в пользовательском интерфейсе, который Вы предоставите для управления тегами.

Скажу честно, моё личное мнение, нынешний интерфейс управления тегами мне не нравится. Пользуюсь сервисом месяц. Во-первых плохо, что визуально теги помещены в общий текст с комментариями. Это уже сбивает с толку, трудно читаемо и воспринимаемо. А Вы туда же хотите затолкать и получателя. Во-вторых, то дерево, о котором Вы говорите, реализовано тоже малоюзабельно. К примеру, ветки не сворачиваются. У меня уже сейчас дерево не влезает в экран, а скроллить его отдельно невозможно, только вместе со страницей, и из списка этого дерева я постоянно вылетаю. Поэтому для меня этот вид представления уже сейчас неудобен. А представьте, будет ветка "Получатели", и в ней несколько десятков наименований? В третьих, отчет по корню какой либо ветки тегов не делается, то есть корень ветки тегов не имеет для себя никакого дополнительного функционала.

В общем, резюме таково. Да, получателей можно описать тегами. Это технически проще, надежнее. Но пользовательский интерфейс управления тегами потребует серьезной доработки.

И потом, у тегов есть один большой минус - будучи добавленными к описанию операции они теряют визуальную принадлежность к смысловым группам (веткам дерева), так как перечисляются под операцией единым списком без отображения иерархии. То есть даже если Вы сделаете удобный интерфейс управления тегами, то все равно визуально все теги разной смысловой нагрузки будут общим списком под операцией, глазами вычленять тяжело, и в голове нужно производить постоянно анализ по принадлежности тега к смысловой группе. Что не пришлось бы делать, если бы Получатель хранился визуально в отдельной колонке или отдельном поле, выделенным каким-либо стилем шрифта. Сам факт расположения текста в определенной области и/или в определенном виде означал бы его смысловую принадлежность. Это просто удобнее воспринимать.

Вы же вычленили категории отдельным визуальным представлением. Зачем? Потому что так нагляднее. С Получателем та же история.

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

Теги по смыслу расширяют описание только последнего вопроса - за что заплатил, так как он самый нечеткий и требует глубокой классификации. Все остальное - данные строго определенного типа, не требующие классификации. Хотя, конечно, получателей также можно иерархировать. Но тогда поле Получатель должно иметь свою обособленную категоризацию и/или тегизацию (кривое слово, но смысл, думаю, понятен), и не пересекаться с полем назначения траты. Это было бы идеально.
maskman
17 марта 2015 16:34
kirillov.s.v Пишет:
Теги по смыслу расширяют описание только последнего вопроса - за что заплатил, так как он самый нечеткий и требует глубокой классификации.
Как вариант решения вашего спора.
Привязать теги к категории расходов.
Например, я выбрал Категорию "Продукты" и вижу только теги названия магазинов.
Выбрал категорию Бензин - названия заправок
И так далее.
kirillov.s.v
17 марта 2015 16:45
Частично это могло бы решить проблему большого числа получателей. Но могут возникнуть ограничения. Например, хотдог на заправке. Или канистра в Ленте. С многопрофильными получателями будут проблемы.
maskman
17 марта 2015 16:50
kirillov.s.v Пишет:
Но могут возникнуть ограничения.
Так в том то и прелесть что один и тот же тег может быть в разных категориях.
kirillov.s.v
17 марта 2015 17:01
maskman Пишет:
Так в том то и прелесть что один и тот же тег может быть в разных категориях.
А, ну да, об этом не подумал. Да, неплохой вариант.
Но этого недостаточно для удобной работы с получателями, это только часть решения.
Admin
 
30 мая 2015 16:25
Приложение для Андроид с поддержкой https://www.drebedengi.ru...arser - вышло.
Вячеслав
30 мая 2015 18:48
Сделал тестовые перевод на карту Билайн и платёж с этой же карты. От момента платежа до появления информации на сайте прошло меньше 15 сек. Пока всё отлично! Разработчикам большое спасибо!
scenic
31 мая 2015 19:12
не понял как пользоваться автоматическим вводом трат. настроил в приложении номера - 900 (сбербанк), KYKYRYZA.RU (Карта Кукуруза евросети), Citialert (Ситибанк), настроил правила на сайте. Нажимаю Синхронизировать - ничего не происходит, в истории обработки пусто. Что я делаю не так?
Admin
 
1 июня 2015 10:24
scenic Пишет:
Нажимаю Синхронизировать - ничего не происходит, в истории обработки пусто
Здравствуйте.
Будут обрабатываться только новые СМС. Старые не обрабатываются.
Посмотрите на странице описания, как работает автоматическая обработка.
scenic
1 июня 2015 12:24
Admin Пишет:
Будут обрабатываться только новые СМС. Старые не обрабатываются.
Добрый день!
уже после настройки правил и приложения приходили смс с номеров которые я добавлял в приложении, интернет работал на телефоне, никаких трат не добавилось.
Admin
 
1 июня 2015 12:28
Не могли бы вы показать скриншот с СМС, которая не попала в историю обработки (должен быть виден номер с которого оно пришло и весь текст), а так же заполненную в приложении форму, с этим номером?
Вячеслав
1 июня 2015 12:56
Нововведение замечательное, ноесть предложение по доработке.
Сейчас СМС, не удовлетворяющие ни одному правилу, просто игнорируются. Из-за этого у пользователя будет возникать беспокойство: все ли суммы занесены в Дребеденьги (далее, ДД) или что-то напрасно проигнорировано (например, я неправильно задал правило, или банк поменял шаблон текста)? Придётся периодически сверять СМС-ки с отчётом в ДД.
Поэтому предлагаю подумать в следующем направлении: т.к. СМС - это по сути аналог чека, то сделать для поступивших СМС аналогичный чековому интерфейс. С указанием статуса (обработан, проигнорирован и т.д.).



Чтобы быть увере
Admin
 
1 июня 2015 12:59
Вячеслав Пишет:
то сделать для поступивших СМС аналогичный чековому интерфейс. С указанием статуса
Здравствуйте.
Такие статусы указываются в истории обработки, в программе.

Уточните, какое именно сообщение у вас было игнорировано и какой у него статус обработки?
Вячеслав
1 июня 2015 13:02
Admin Пишет:
Уточните, какое именно сообщение у вас было игнорировано и какой у него статус обработки?
Не-не, у меня всё хорошо, спасибо. Это было просто предложение по дальнейшему развитию функции.
А в программе проигнорированные сообщения будут тоже попадать в историю обработки?
Admin
 
1 июня 2015 13:04
Вячеслав Пишет:
А в программе проигнорированные сообщения будут тоже попадать в историю обработки?
Да, с соответствующим статусом.
1 2 3 4 5  Туда  
Чтобы отвечать на сообщения - зарегистрируйтесь и войдите в личный кабинет.