> Коллеги, приветствую.
>
> Начинаю автоматизировать кое-что в гос структуре.
> Среди прочего, часто появляется задача, которой стараюсь избегать.
>
> Дано:
> 1. Извне периодически поступают документы в формате Word/Excel/Html...
> (обобщим — текстовые).
> 2. Документы пишутся людьми, на которых повлиять нельзя.
> 3. Формат текста в документах (расположение ячеек, абзацев, полей,
> форматы чисел, дат, валют и т.п.) определяется авторами документов.
> По наблюдению, формат повторяется из раза в раз, но в действительности
> он не является строго заданным, шаблонным и иногда может варьироваться
> по желанию авторов документов.
> 4. Есть автоматизированная информационная система, в которую вручную
> заносятся в формализованном виде определенные данные, извлекаемые из
> поступающих текстовых документов.
>
> Задача:
> Автоматизировать извлечение данных из поступающих документов и занесение
> их в базу данных системы.
>
> Вопрос:
> Какие архитектурные подходы и идеи Вы можете предложить для реализации
> программной системы, решающей (частично решающей) описанную задачу?
> Наверняка многим из Вас приходилось сталкиваться с подобными проблемами.
> Что делалось и чем это закончилось у Вас?
> Извлечение данных из полуформализованного текста

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

На удивление жизнеспособной идеей оказалась такая.

Страница 1: Поле textarea в которое нужно скопировать текст из икселя
через буфер обмена. Тогда сами по себе получаются разделители (конец
строки разделитель записей, табулятор — разделитель столбцов).
Кнопка сабмит (переход на страницу 2)

Страница 2: Html-таблица со всеми данными. В заголовке таблицы над
каждым столбцом находится DropDownBox (<select>) в котором перечислены
все столбцы относяциеся к товарной позиции и к поставщику. Что-то вроде
наименование, цена, вес, производитель, фио, фамилия, имя, телефон, адрес...
Пользователь должен над каждым столбцом выбрать назначение столбца.
Сабмит — переход на страницу 3 (некоторые столбцы обязательны, и на
странице 2 они обязательно должны быть указаны, иначе переход не
производится). Можно выбирать одно и то же наименование для нескольких
столбцов, тогда данные из этих столбцов объединяются (чаще всего
комментарии и телефоны)

Страница 3: Сообщение сколько записей, сколько поставщиков, сколько
записей без поставщиков. Список поставщиков, так, как они опознались из
исходных данных и дополнительно поля для ввода всех атрибутов
поставщика. Напротив каждого отображается выбранный из уже
зарегистрированных поставщик, либо пусто (типа это новый поставщик).
Также напротив каждого поставщика ajax формочка для поиска и выбора
поставщика (если алгоритм сам не сможет найти, пользователь ищет и
выбирает). Одна запись (если есть записи без поставщика) типа дефолтный
поставщик. У этой записи тоже есть поля для ввода всех атрибутов. Также
как и для всех остальных поставщиков, можно найти в базе уже
зарегистрированного и выбрать его.
По сабмиту производится запись данных в базу. При этом, заносятся новые
поставщики (если нужно), а каждая товарная запись проверяется по базе и
либо добавляется либо обновляется (например при изменении цены).

Страница 4: Такая же textarea как на странице 1, но в ней все строки,
которые не прошли (например в столбце цена написано "договорная", а в
базе там ожидается decimal). Пользователь может ручками поправить и
перейти на страницу 2 (повторный ввод). все как раньше (только на второй
странице столбцы уже выбранные, как в первый раз).
Также на странице 4 (выше textarea) краткий отчет:
Обработано: 500 строк
Поставщиков: 2
Добавленно товаров: 240
Обновлено товаров: 260
Добавлено поставщиков: 1
Необработанных строк: 3
(это примерно, я уже не помню что там было конкретно).

Этот подход разрабатывался по идеям заказчика и вместе с ним. Реализация
была кошмарная (на обновление 500 строк производилось 1500 SQL
запросов). Работало медленно, за раз прожевывало не более 6 тысяч строк
(на эти 6000 строк могло уйти 3-4 минуты).
Когда сделали, заказчик посадил девочку-секретаря и она за полтора
месяца забила несколько сотен тысяч предложений в эту систему. Из всяких
разношерстных прайслистов, из веба, из вордовских документов. Было еще
довольно много бумажных факсов, которые она распознала файн-ридером и
тоже занесла в базу!
После чего уже менеджеры-продавцы сами регулярно пополняли систему.
Оказалось менеджеру легче один раз засунуть прайс-лист в систему и
пользоваться его данными там (никого не пришлось заставлять). Благодаря
проверке записей при вставке менеджеры, если не знали занесен ли
некоторый прайс лист в базу, не парились, а тупо заносили его по-новой,
дубликатов-то не возникало.

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

Коллеги, приветствую.

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

Дано:
1. Извне периодически поступают документы в формате Word/Excel/Html... (обобщим — текстовые).
2. Документы пишутся людьми, на которых повлиять нельзя.
3. Формат текста в документах (расположение ячеек, абзацев, полей, форматы чисел, дат, валют и т.п.) определяется авторами документов.
По наблюдению, формат повторяется из раза в раз, но в действительности он не является строго заданным, шаблонным и иногда может варьироваться по желанию авторов документов.
4. Есть автоматизированная информационная система, в которую вручную заносятся в формализованном виде определенные данные, извлекаемые из поступающих текстовых документов.

Задача:
Автоматизировать извлечение данных из поступающих документов и занесение их в базу данных системы.

Вопрос:
Какие архитектурные подходы и идеи Вы можете предложить для реализации программной системы, решающей (частично решающей) описанную задачу?
Наверняка многим из Вас приходилось сталкиваться с подобными проблемами. Что делалось и чем это закончилось у Вас?

Здравствуйте, MikhailVi, Вы писали:

Я вижу так.
С одной стороны документ изначальный, из него нужны "№, дата, автор, текст, ....".
С другой стороны по полям "№, дата, автор, текст, ..." переходим автоматически,
пользователь только нажимает мышкой на текст изначального документа.
Тест выделяется сразу слово/строка/абзац/... если выделено что нужно (ввод, кнопка мышки) данные переносятся в поле и переход на следующее.

Здравствуйте, MikhailVi, Вы писали:

MV>Коллеги, приветствую.

MV>Начинаю автоматизировать кое-что в гос структуре.
MV>Среди прочего, часто появляется задача, которой стараюсь избегать.
...
MV>Какие архитектурные подходы и идеи Вы можете предложить для реализации программной системы, решающей (частично решающей) описанную задачу?
MV>Наверняка многим из Вас приходилось сталкиваться с подобными проблемами. Что делалось и чем это закончилось у Вас?

Ну, нужно понимать, что в общем виде задача решения не имеет. Тогда всё становится проще.

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

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

первая задача, в свою очередь, разбивается на создание пар — признак определенного класса формата (скажем — источник) и собственно набор возможных парсеров для этого семейства

Дальше гоняете свои парсеры по тестовому набору документов, строчите массу кода вида "ищем число в ячейке, находящейся справа или снизу от ячейки с текстом 'Итого:', если находим то..." и добиваетесь заданного заказчиком процента автоматического распознавания.

В процессе приходится писать всевозможные helper-ы, типа "распознавание даты даже в случае, если название месяца написано с ошибкой" и много регулярных выражений.