Перенос позиций КП через OCR: как вытащить строки из PDF

Четверг, 16:20. Перед специалистом по коммерческим предложениям лежит отсканированный прайс-лист поставщика на девять страниц: больше двухсот строк, слегка перекошенные края сканов, на полях от руки дописаны примечания. Клиент ждёт предложение завтра утром. Специалист начинает вбивать строки вручную и через сорок минут, где-то в середине списка, замечает, что в одной цене запятая ушла на разряд. Теперь перепроверять нужно не только эту строку, а всё, что набрано до неё. Именно так уходит основное время при подготовке предложения: не на то, чтобы продумать сделку, а на то, чтобы перенести строки.

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

Почему PDF не превращается в предложение сам по себе?

PDF — это формат печати, а не формат данных. Он фиксирует, какой символ стоит в какой точке страницы, но не сообщает, что эти символы образуют третий столбец таблицы. То, что глаз читает как «наименование, количество, цена», внутри файла является тремя отдельными текстовыми блоками, случайно оказавшимися на одной высоте. Линии между столбцами чаще всего просто нарисованы и границами ячеек не являются.

Второе различие важнее: у вашего файла есть текстовый слой или это фотография бумаги? В прайс-листе, выгруженном из учётной системы, символы остаются символами. Тот же лист, распечатанный и пропущенный через сканер, — одна плоская картинка, внутри которой нет ни одного настоящего знака. На экране они выглядят одинаково и ведут себя совершенно по-разному. Большинство инструкций о том, как составить коммерческое предложение, этот момент пропускают и просто советуют «импортировать PDF» — а сложность начинается именно здесь.

Третье: позиция предложения — это не кусок текста, а запись. Наименование, количество, единица, цена, скидка по строке и ставка налога должны заполниться каждый по отдельности и правильно. Ошибка в одном поле даёт неверный итог, и именно неверный итог уходит клиенту. Поэтому перенос нужно выстраивать как задачу сопоставления полей, а не как задачу «забрать текст».

Что OCR читает, а что ему не даётся?

OCR — это слой, превращающий формы на изображении в символы. На ровной, чётко напечатанной странице с одним шрифтом эта задача сегодня решается надёжно. Трудность не в символах, а в связях между ними: какая группа слов является наименованием, какое число — количеством, а какое — ценой. Это анализ вёрстки, и работает он ровно настолько, насколько упорядочен исходник.

На практике лёгкие случаи предсказуемы: чётко напечатанные наименования, целые числа, заголовки столбцов, обозначения валют. Тяжёлые тоже: рукописные правки, строки под печатью или штампом, бледная серая печать, описание, разорванное между двумя страницами, длинные названия, переносящиеся на вторую строку из-за узкого столбца. Выстраивая процесс переноса, вы добиваетесь не того, чтобы OCR никогда не ошибался, а того, чтобы заранее знать, где он ошибётся, и поставить там проверку.

Полезно смотреть на это как на раздел той же дисциплины, что и импорт и экспорт данных в CRM. Вопросы те же самые: в каком формате источник, какое поле куда идёт, что происходит с ошибочной строкой и можно ли откатить перенос.

Какой исходник даёт какой результат?

Источники неравноценны. Таблица ниже сводит четыре типа документов, которые чаще всего встречаются при переносе позиций, и то, чего от каждого стоит ждать. Цель — не пообещать процент точности, а показать, какая проверка обязательна для какого источника.

Источник	Структура	Слабое место	Обязательная проверка
Родной PDF из системы	Есть текстовый слой, столбцы выровнены	Объединённые ячейки, промежуточные итоги	Число строк и общий итог
Отсканированный прайс-лист	Изображение, ровная страница	Бледная печать, чтение цифр	Цена в десяти случайных строках
Фотография с телефона	Изображение, наклон и тени	Смещение строк, обрезанный край	Все строки прочитаны от начала до конца
PDF старого предложения	Текстовый слой, знакомый шаблон	Столбцы скидки и налога	Скидка, налог и валюта

Этот порядок одновременно является порядком предпочтения. Просьба «пришлите PDF, который выгружает ваша система, сканировать не нужно» улучшает качество переноса сильнее любой настройки программы. В работе, где позиций много, — например, в типографии — одна такая фраза экономит по полчаса на каждом заказе.

Где ломается распознавание строк?

Перенос почти никогда не разваливается из-за неверно прочитанной буквы. Он разваливается там, где граница строки проведена не в том месте. На четыре случая приходится большая часть проблем:

• Перенесённое наименование. Описание не поместилось в одну строку; вторая строка воспринимается как отдельная позиция — без количества и без цены.
• Объединённая ячейка. Заголовок группы, под которым идут три позиции, попадает в список как позиция.
• Строка промежуточного итога. Итог внизу страницы заходит в список как самая дорогая позиция и удваивает сумму предложения.
• Разрыв страницы. Позиция, оборванная внизу листа, склеивается с шапкой следующего.

Все четыре случая видны глазом. Проблема в том, что в списке из двухсот строк глазами никто не смотрит. Решение — простая привычка: после переноса открыть три самые дорогие строки и три самые дешёвые. Ошибки с итогами и пустыми строками почти всегда стоят на этих двух краях. При подготовке ответа на запрос на производстве такая проверка быстрее чтения спецификации и ловит больше.

Формат чисел, валюта и налог: самые дорогие ошибки

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

Вторая ловушка — валюта. Прайс может быть в долларах, а предложение в рублях; или лист составлен по прошлогоднему курсу. Здесь выручает работа Rocketly с несколькими валютами и живым курсом: курс на момент создания предложения фиксируется в записи, а актуальные курсы подтягиваются из справочника центрального банка. Через три месяца вопрос «по какому курсу считали» решается документом, а не чьей-то памятью.

Третье — налог и скидки по строкам. Прайс-листы обычно приходят без НДС, старые предложения — с ним. Чаще всего именно в этом ответ на вопрос «почему не сходится итог». Один раз отметить на уровне поля, включён ли налог в исходный список, — значит снять сотни последующих правок. То, что делает управление предложениями предсказуемым процессом, в основном и состоит из таких записанных решений.

Кто проверяет перенесённую позицию?

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

В Rocketly эту работу выполняет перенос позиций через OCR: вы загружаете фотографию прайс-листа или старого предложения, наименования, количества и цены заполняются в строки предложения, и вы правите их до отправки. Перенос выдаёт предложение к рассмотрению; решение отправить остаётся за вами. Та же логика действует и для переноса позиций из Excel, где длинные списки приходят одним заходом, а не набираются построчно.

Кто что проверяет — вопрос ролей. Наименования и количества сверяет тот, кто готовит предложение; логику цен и скидок на суммах выше порога проверяет руководитель. Если хочется увидеть, как вообще устроено сопоставление полей, мастер сопоставления полей при импорте из Excel показывает ту же механику на стороне лидов: привязка исходного столбца к целевому полю и отсев ошибочных строк работают одинаково.

Прайс-лист или старое КП? Два разных сценария

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

Для прайс-листа правильный рефлекс — превратить вычищенные строки в набор для повторного использования. Для этого в Rocketly есть галерея готовых шаблонов: вы берёте готовый набор позиций по отрасли и сохраняете его как собственную заготовку. Следующее предложение уже не потребует повторного распознавания того же листа.

Со старым предложением вопрос иной: сколько из прошлогодней цены действует сегодня? Перенести строки — лёгкая половина работы; тяжёлая — решить, какие из них надо пересчитать. В команде, у которой есть рабочий шаблон коммерческого предложения, это решение уже заложено в шаблон: какие позиции постоянны, какие пересчитываются каждый раз, какие опциональны.

Как предложение доводится до готовности после переноса?

Когда строки на месте, предложение ещё не готово. Дальше идёт превращение строк в документ: группировка, вынесение опциональных позиций, текст условий, срок действия и оформление. На этом этапе скорость переноса уступает место суждению.

Две вещи заметно облегчают этот этап. Первая: длинный перенесённый список не должен уходить клиенту как есть — благодаря выбору пакета и частичному принятию клиент выбирает между вариантами или подтверждает только нужные позиции, и выбор записывается в предложение. Вторая: предложения, превышающие порог суммы или опускающиеся ниже минимальной маржи, попадают в очередь согласования и не уходят клиенту без одобрения, а решение записывается в историю версий. Кто именно согласовал скидку, пришедшую из переноса, через три месяца не станет предметом спора.

Если смотреть на конфигурацию позиций целиком, логика «конфигурация — цена — предложение» показывает, где стоит перенос: OCR питает первый шаг, а правила ценообразования и сборка документа идут после.

Как выглядит план внедрения на две недели?

Попытка запустить всё за один день обычно заканчивается тем, что после первого неудачного предложения инструмент бросают. Поэтапный план работает лучше:

• Дни 1-3. Возьмите три исходных документа, с которыми работаете чаще всего. Перенесите каждый один раз и сверьте результат построчно с вариантом, набранным вручную. Цель — не идеальный результат, а понимание характера ошибок.
• Дни 4-6. Превратите найденные типы ошибок в чек-лист: промежуточные итоги, перенесённые описания, разделитель дробной части, статус налога, валюта.
• Дни 7-10. Сохраните повторяющиеся наборы позиций как заготовки. Частые позиции теперь выбираются, а не распознаются.
• Дни 11-14. Запишите порог согласования и распределение проверок, чтобы было ясно, чьи руки черновик миновать не может.

В конце второй недели измерять стоит только две вещи: время подготовки предложения и число исправлений после отправки. Если второе не снижается, перенос стал быстрее, но не стал надёжным. Команды, которые уже следят за тем, как отправленное предложение превращается в сделку, держат эти два числа рядом; аналитика по предложениям и выгрузка позволяют забрать данные в CSV и положить в собственный отчёт.

Пишет ли перенос текст самого предложения?

Нет, и эту границу стоит удерживать. Перенос через OCR заполняет таблицу позиций; убеждающая часть — описание объёма работ, критерии приёмки, обоснование — это отдельная работа. Настоящая выгода быстрого переноса в том, что сэкономленное время можно вложить именно в этот текст.

На практике работает такая последовательность: сначала перенести и проверить строки, затем написать объём работ, в последнюю очередь настроить оформление. Команды, идущие в обратном порядке, размещают неверные строки внутри красивого документа. Это же является условием для того, чтобы получать убедительное предложение из контекста: контекст должен быть верным, иначе сгенерированный текст красиво изложит неверные данные.

Если хотите проверить схему на своих списках позиций, откройте аккаунт и начните с переноса одного прайс-листа.

Частые вопросы

Достаточна ли точность на сфотографированных списках?

Если снимок сделан на ровной поверхности, без теней и вся страница попадает в кадр, результат обычно рабочий. Наклон, блики и мятая бумага чаще всего вызывают смещение строк. Если у вас есть выбор источника, PDF из системы всегда даёт лучший результат.

Можно ли откатить перенос, если строки неверны?

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

Нужен ли OCR, если есть Excel?

Если есть Excel, используйте Excel — он всегда чище. OCR нужен там, где вторая сторона прислала только PDF или лист бумаги. В большинстве команд работают оба пути: собственный каталог из Excel, списки поставщиков через OCR.

При какой длине списка это оправдано?

Примерно до пятнадцати строк быстрее набрать вручную. Выигрыш живёт в длинных списках: с ростом числа строк и время, и вероятность ошибки ручного ввода растут быстрее, чем сам список.