Анализ магазинных чеков

Оказывается, есть такой новый закон об онлайн-кассах. Это когда продавцы обязаны пересылать все свои чеки в единый государственный орган в онлайн-режиме.
Для покупателя выгода заключается в возможности сходить на специальный сайт (сейчас можно через специальное же приложение для Андроида, например) и проверить чек. Для этого на чеке печатают три магических числа и QR-код, в котором сразу всё необходимое зашифровано.
Что если собрать много чеков и занести всю инфу из них в локальную базу?

Итак, у нас есть:

  1. Идентификатор и название магазина.
  2. Дата продажи.
  3. Название, количество и цена для каждого товара.

Используя всё это и имея достаточное количество записей в базе, можно:

  1. Собрать статистику для каждого покупателя. Сколько шоколада он ест, сколько пива пьёт и сигарет выкуривает. То, чем занимаются всякие приложения для домашней бухгалтерии.
  2. Сравнить цены в разных магазинах. У нас тут всего пять-шесть крупных продуктовых сетей, и, сопоставив товары из них, можно посчитать выгоду чека по сравнению с другими магазинами. Ну и в следующий раз проголосовать рублём.
  3. Собрать историю изменения цены на важные товары. Проверить, правду ли говорят в госорганах про уровень инфляции, покупательскую способность и прочее.

Получать информацию будем не совсем прямым путём. Подглядывая в логи вышеупомянутого Android-приложения, можно найти адресок, куда надо слать данные из чека, чтобы в ответ получить JSON. Можно было бы не подглядывать, если бы государство предоставило открытое API, но беглое гугление ничего такого не подсказало.

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

Есть ещё идея каким-то образом определять в каждом случае оператора фискальных данных и получать ответ с его сервера, то есть как бы агрегировать инфу из разных источников. Пока под вопросом. Пока буду накапливать записи в базе.

Что касаемо технической части, всё написано на старом-добром Django, хранится в SQLite, запускается на Nginx и uWSGI. Код традиционно доступен на GitHub.

Добавить комментарий

Ваш e-mail не будет опубликован.

Поставьте галочки правильно (как бы защита от спама):

Я бот

Я не бот