Кейс: как распознать 790 000 чеков за три недели и не сойти с ума

Привет! Сегодня я вам расскажу, как мы сделали систему распознавания чеков для FMCG заказчика и не захлебнулись на объеме.  

Слушай

Сжатые сроки и неназванный заказчик

В лучших традициях digital-интегратора, к нам пришел клиент, которого нельзя называть, и сказал, что ему уже вчера надо было сделать систему, которая «может все», и при этом ни разу не упадет. В данном случае, под «может все» подразумевалась система распознавания чеков. Да, тех самых обычных кассовых чеков.

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

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

Но хватит занудничать, давайте к кейсу.

Бизнесовая цель

Тут все просто и понятно. Надо распознавать чеки.

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

Больше, по правилам хорошего тона (NDA), я говорить не буду. Что заказчик делает с этими данными, будем считать, нам не сказали, но намекну, что это выгодно для покупателя товара.

Как работает?

Пользователь грузит фотку чека из чат-бота, мы читаем QR, распознаем, что там внутри, берем эти данные, и «идем» с ними в налоговую. ФНС возвращает в ответ содержимое чека, мы ищем нужный нам товар, кладем его в базу, и формируем отчет для клиента.

Процесс

Есть смысл описывать что «мы вели клиента по стандартным этапам»? За две недели многие заказчики не успевают и договор прочитать, а исполнители принять правки к нему. А тут мы и подписаться успели, и разработать, и успешно стартануть.

Из-за того, что все так классно получилось, мы и пишем этот кейс 😊 Мы, разумеется, разбили работы по этапам. В лучших традициях итеративной разработки, взяли тот функционал, без которого и проект не проект, и начали делать его в первую очередь. Когда пошли загрузки чеков, уже докручивали все остальное.

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

Дальше - про то, как мы докрутили каждый из этапов и как его тестировали, думаю, что никому не интересно. Главное знать, что мы справились.

Особенности

Отличие кейса от всех остальных проектов, запущенных по подобным «лекалам», заключается в следующем:

1. Сжатый срок. Времени у нас было две недели на всю эту красоту.
2. Большой объем данных СРАЗУ. Это можно расценить как плюс, что было достаточно чеков, чтобы протестировать со всех сторон. Но и как минус, что эти чеки надо было сразу распознавать и сразу выдавать результат. Не было «права на ошибку и отладку», так скажем.
3. Плохое качество фото. Тот же самый, например, "Едадил", легко может сказать «не удалось распознать QR», или просто молча не распознать. У нас такой роскоши нет, поэтому родилась следующая особенность:
4. Если мы не смогли распознать QR, то отправляем чек на ручную модерацию. Это делается уже на стороне клиента. Такой объем мы бы сами замучились распознавать. НО! Это рождает, как вы уже поняли, админку, куда сыпятся эти чеки, и некий «механизм ручной модерации». Этот самый условный модератор, открывая фото, должен куда-то ввести данные, которые смог распознать своими глазами. И это опять улетает в ФНС, и т. д.
5. Аналитика, мониторинг, бекапы, хранилище. Да, мы умудрились не просто сделать чтобы оно работало, а еще и не падало, и бекапилось, и строило красивые графики, и даже мониторилось (если этот пункт не понятен, почитайте мою прошлую статью).

На сладкое

Чеков за все время мы распознали порядка 790 000 штук. Точное количество назвать сложно, потому что они прибывают с каждой минутой. В первую неделю после запуска распознавателя – было загружено порядка 120 000 чеков. Если рассуждать по-простому, то это примерно по 12 чеков в минуту. Каждую минуту. Если считать, что в сутках 24 часа. Естественно, чеки грузили в основном в рабочее время, что увеличивает нагрузку вплоть до 30шт/мин.

Отдельно акцентирую внимание, что мы храним каждую фотку. Даже если считать, что каждая весит по 2 МБ (телефоны, в наши дни, делают фотографии примерно с весом 2-5 МБ), то 790 000 шт по 2 МБ это почти 2 ТБ. Только файловое хранилище. Напомню, что мы не Яндекс, и своих датацентров еще не построили. А мы их еще и бекапим, чтоб не потерялось.

Наверное, к этому моменту вы хотите узнать, сколько это удовольствие стоило? Это мы раскрывать не можем, но спасибо, что дочитали досюда 😊

Если интересны технологии, на которых это все было реализовано, или еще какие-то детали, то напишите комментарий. Может, еще на одну статью наберется, и я опишу более подробно.

Наш Telegram-канал, куда выкладываем подобные новости: https://t. me/botcreatorsru