Доброго времени суток.
Меня зовут Алексей, я программист 1С и у меня есть идея, которая может быть полезной, а следовательно приносить прибыль, более того есть работающий прототип, но, прежде всего, нужна обратная связь от людей, а надо ли это вообще? Данным постом я прежде всего хочу отметить для себя, надо ли мне тратить уйму часов своей жизни для развития данного продукта, если он никому не нужен? Начну по порядку.
Компания, в которой я работаю занимается продажей техники отдельных брендов, то есть отдельный магазин Samsung, отдельные магазины Sony. Продажа идет по рекомендованной розничной цене, которая для основной техники практически совпадает с ценой закупа, таким образом, рентабельность магазинов очень мала, грубо говоря не ноль только благодаря аксессуаром и услугам. Прибыль с продажи телефонов получается с помощью бонусов: при продаже определенной техники, в определенный период, и/или при закупе определенного количества техники компания-бренд начисляет деньги и, или их выплачивает, или зачитывает как оплату закупа
Всё бы хорошо, но для корректного отображения рентабельности магазинов в 1С необходимо учитывать данные бонусы в валовой прибыли и в доходах/расходах. Информация по данным бонусам передается по ЭДО и описывается на какие модели, на какой период, какая сумма начисляется при продаже либо при закупе. Задача была загружать эти данные в 1С. Просто так выгрузить из ЭДО не получается, заказывать отдельную интеграцию с ЭДО. Вышло достаточно дорого и компания не готова была это оплачивать, поэтому пришлось выгружать документы как PDF и заносить вручную менеджерам. А вот тут началось самое скверное: данные документы могли быть по несколько десятков страниц с таблицами с несколько десятками BOM-кодов на каждой, и это нужно было делать постоянно. Попросили решить данную проблему.
Я всесторонне подошел к данной проблеме и пришёл к выводу, что наиболее адекватный вариант решения — это преобразование страницы в формат, который сохраняет структуру данного документа и мне нужно написать парсер, который бы получал информацию с данной структуры. В качестве OCR программы я перепробовал много, но более или менее внятный результат получил от продуктов ABBYY, сначала через льготный период FineReader, а потом и через API. Стал преобразовывать PDF в HTM (XML при API, все нижесказанное справделиво и для сканов, которые я потом тоже преобразовывал в HTM) и пытался разобрать. Но появилась проблема. OCR распознавала текст не всегда точно и тупо привязаться к названию колонок, областей не мог и, решив вспомнить своё математическое образование, придумал оригинальное решение. Назовём узлом либо часть текста, либо ячейку таблицы (только шапки таблицы в некоторых случаях), таким образом, совместив рядом стоящие узлы, получим граф, более того данный граф, скорее всего, уникален для данного документа и, заведя условный граф-шаблон, где для каждого узла прописано как мне извлекать информацию, я могу рассматриваемый граф сравнивать с шаблонами, выбирать нужный и PROFIT! Но снова проблема.
OCR, даже от ABBYY, часто некорректно распознавал таблицы: часть ячеек он объединял как одну, реже, но разбивал ячейку на две, поэтому просто искать на равенство структур не получалось. В таком случае нужно искать наиболее похожий граф, а это уже на порядок более сложная задача, которая до сих пор полностью не решена. Но «полностью» это не про этот случай, тут задача достаточно частная. Стал искать решение. Для начала сформулировал проблему. Нужно один граф сравнить со множеством других, при этом мне нужно знать как конкретно они отличаются, то есть какие узлы в шаблоне нужно разделить/соединить, чтобы получить рассматриваемый граф, ведь из этого я могу уже корректировать правила извлечения данных.
После нескольких недель штудирования матчасти, рефлексии о безысходности, плача менеджеров, что им так плохо и нужно быстрее всё автоматизировать, я придумал эвристический алгоритм, который решал проблему. Алгоритм строится на следующих принципах:
1) Так как файл в HTM (XML) формате, то я могу каждый блок текста, каждую ячейку особым образом пронумеровать, а в шаблоне всё уже пронумеровано.
2) Предполагаю, что граф и рассматриваемый шаблон одинаковы, а из этого следует, что ребра каждого узла одинаковы. Таким образом, достаточно сравнить ребра каждого узла.
Суть алгоритм такая: обозначу рассматриваемый граф Г, а шаблон Ш, строю новый граф Н.
— беру n узел графа Г и графа Ш,
— сравниваю ребра n+1 узла,
— выбираю что выгодней, либо n+1 узел из Г вставить с его ребрами в Н, либо из Ш в Н, либо вставить узел в Н с объединенными ребрами и из Г и из Ш, перехожу к следующему узлу.
Данная, с виду простая, методика дала очень хороший результат и скорость. Граф более чем в тысячу узлов сравнивался не более нескольких секунд и выдавались конкретные места ошибок. На данном алгоритме я построил парсер, который определял структуру таблицы и получал правила загрузки информации в 1С, которые указал сам пользователь. Менеджеры конечно были в восторге — больше года это используют, но даже спасибо не сказали, но не важно. Данный подход я стал тестировать на других документах и оказалось, что УПД, счета-фактуры, УКД, Торг-12, просто счета на оплату, разного рода анкеты, разного рода внутренние документы, экселевские файлы с таблицами, htm файлы сайтов, любые структурированные данные — все они по своей структуре могут быть определены. А следовательно можно самому пользователю задать шаблон с правилами по извлечению информации — это позволит сделать парсер универсальным, дать простую настройку для сложной задачи для широкой массы пользователей. Более того, в идеале, если сделать мобильное приложение, которое сканирует и распознаёт таким образом бумажный документ, то можно прямо с телефона получать и загружать нужную информацию в 1С, что делает ненужным покупку сканера для микро и малого бизнеса, не говоря уже об экономии времени.
Решил сделать стартап, так как чисто эмпирически данная вещь очень полезная для многих компаний. Но снова проблема. В стране идет курс на цифровизацию, и все говорят, что мой проект — это конечно замечательно, но ЭДО рулит, бумага уйдет в историю в ближайшие годы и никому это не надо. ЭДО действительно поднимает голову, его объёмы растут не по дням, а по часам, но по исследованиям бумажный объём растет паралельно с этим, и ЭДО часто дублирует работу, к примеру так как я описывал в начале. ЭДО сильно дороже пересылке по электронной почте сканов или PDF. Юридическая значимость сканов, PDF прописывается в договоре, а значит может быть дешёвым аналогом ЭДО. Я согласен, что за ЭДО будущее, но скорее в далёкой перспективе.
Данный проект отличается от остальных тем, что сам пользователь выбирает нужный OCR, а мой алгоритм универсально спарсит информацию так, как это нужно пользователю. Более того сейчас решается вопрос об использовании связки OpenCV + Tesseract, что позволит и так достаточно дешёвый способ превратить в практически бесплатный. Но тут ключевой вопрос — а надо ли это пользователям вообще? Прошу написать комментарии, чтобы понять нужно ли двигать проект.
Спасибо за внимание.