Когда-то несколько лет назад, когда мы изучали представленные на рынке решения для работы с электронными формами и возможность их применения у наших клиентов, то обратили внимание на один интересный факт - если в мире имеется огромное множество продуктов для работы с электронными формами, приняты и развиваются ряд добротно проработанных стандартов, и вообще, по всей видимости, практически ни у кого не возникает вопрос по поводу того, что такие за звери e-forms, и для чего они нужны, то у нас в стране электронные формы используются крайне неохотно (не скажу, что не используют вообще, нет конечно, используют, но, даже в таких областях как, например, розничная торговля, страхование, кредиты, ... - предпочитают зачастую либо печатать бланк, отдавать на ручное заполенение, а потом обратно вводить данные (при хорошем раскладе здесь будет использована система распознавания бумажных форм), либо использовать собственные решения, где оператор вводит данные со слов клиента, а потом просто распечатывает все в виде отчета).
Что тому причиной, я не знаю, возможных вариантов много: и ориентация на в целом невысокую компьютерную грамотность (хотя то, что было актуально еще в начале 2000-х годов, сейчас почти неправда), и укоренившееся в сознании главенство бумажного докмента, и Бог его знает что еще... Но вот одно из таких потенциальных препятствий, мне хотелось бы обсудить, и даже, если получится свеcти его на "нет". Этим препятствием, является то, что, в основном, работа с электронными формами реализуется специальными средствами, с которыми большинство пользователей компьютеров не сталкивались вовсе или что-то слышали, но слабо представляют что это и зачем нужно. Ну скажите, многие ли в работе сталкивлись с такими продуктами как Microsoft InfoPath или Adobe Acrobat (хотя слышали о них многие), а скольким приходилось хотябы слышать, например, об IBM Workplace Forms (кроме тех, конечно, кто внедряет или использует решения на базе Lotus)?! Собственно, по моим ощущениям, перечисленные продукты (впрочем, как и все остальные продукты для работы с электронными формами) у нас в России, почему-то, воспринимаются как некий аналог редактора экранных форм в какой-нибудь популярной среде разработки - т.е. считаются, инструментом разработчика, а не пользователя ("а зачем нам еще один редактор форм для программиста - ему и своего хватает, да он и сам говорит, что оно ему не надо - он сделат лучше")!
Поэтому, узнав что инструменты для работы с электронными формами (хотя сами разработчики предпочитают обходить этот термин - что в общем-то понятно, для электронных форм есть InfoPath) в Word 2007 был серьезно переработан, я выбрал время чтобы познакомиться с ним по-подробнее. И результат, должен признать, меня ничуть не разочаровал! А приведенный ниже пример, надеюсь, кому-то сможет помочь начать использовать новые возможности.
Однако, прежде чем приступать к практической части, давайте кратко обсудим, какие потенциальные возможности предоставляет использование электронных форм. Я бы выделил следующие плюсы:
Структуризация и, как следствие, упрощение ввода и контроля вводимых пользователем данных. Например, если в качестве электронной формы Вы используете шаблон заявления, то можно явно в тексте выделить поля (а также указать их тип, и, если позволяет среда для заполнения форм, выбрать элемент управления, который будет использоваться при вводе) для ввода имени и реквизитов заявителя, дат документа, его номера (который может заполняться автоматически), и других обязательных реквизитов. Если среда при этом позволяет, то можно прямо "на лету", проверять корректность заполнения полей. Соответсвенно, будет меньше ошибок ввода и меньше ручной работы по проверке.
Возможность автоматической обработки данных форм. От элементарного: "достать данные из полей и положить их в один Excel-файл, а там что надо, пусть то и делают", до полноценной автоматической обработки форм в полностью автоматических процессах. Для обычного неструктурированного документа сама задача "достать данные" может превратиться в крайне нетривиальную задачу анализа форматирования, взаимного расположения частей, а иной раз и содержимого текста.
Ну все, хватит общих разглагольствований, давайте посмотрим, как и чего можно добиться, взяв за основу Microsoft Word 2007...
Итак, представьте себе такую задачу - к Вам обращается секретарь или бухгалтер занятый(ая) обработкой заявлений на отпуск от работников вашей компании. В вашей компании довольно высокий уровень автоматизации и все основные документы почти полностью ходят только в электронном виде (печатают документы только на последних этапах, и только те, где нужна живая подпись). Для упрощения заполнения наиболее частых документов давно разработаны полуготовые шаблоны, в которых вместо специльно выделенных подстановочных строк нужно вписать свои. Что-то вроде шаблона, который приведен на рисунке:
Форма шаблона совсем не сложная, но всегда найдется кто-то "особо одаренный", который умудится что-то напутать, написать лишнего или просто случайно стереть лишнее. А компания у вас достаточно большая чтобы процент таких одаренных стал бы серьезной проблемой... А потому, за работу!
Первым делом, вместо строчек вида [ФИО заявителя] мы вставим поля ввода. Найти эти поля можно на закладке "Разработчик", в группе "Элементы управления":
Для задания наших полей мы воспользуемся следующими элементами:
Текст для поля [ФИО заявителя]
Поле со списком (или раскрывающийся список) для полей [год_нач] и [год_кон]
Выбор даты для [дата_нач], [дата_кон], [дата_вых] и [дата_подписи]
В результате наш документ приобретет примерно следующий вид (все прежние поля ввода заменились серым текстом с надписями навроде "Место для ввода даты", причем при если щелкнуть на любой из них будет видно, что это поле ввода):
Теперь нужно пройтись по всем только-что вставленным полям ввода и указать для них дополнительные настройки. Вызвать окно свойств для поля можно выбрав его, и нажав кнопку "Свойства", все в той же группе "Элементы управления". В свойствах мы укажем:
названия полей
для полей с датами - формат отображения "dd.MM.yyyy"
для полей с выбором (которые у нас представляют года) - перечислим несколько лет.
Окно свойств, например, для поля с выбором будет выглядеть примерно следующим образом:
Собственно, вот и весь первый этап. Теперь для каждого значимого поля у нас отведен свой элемент ввода, а для отдельных полей использованы даже специальные элементы, как "выпадающий список" или "календарь":
Результат не плох, однако, остается еще одна проблема - случайная порча остального текста документа (от серьезной преднамеренной порчи, увы, защититься куда как сложнее). Чтобы защитить документ от случайного изменения мы воспользуемся той же закладкой "Разработчик", выбрав пункт "Защитить документ", а в нем включив элемент "Ограничить форматирование и редактирование":
В результате откроется панель ограничения форматирования и редактирования, в которой мы последовательно:
Поставим галочку "Разрешить только указанный способ редактирования документа" и в качестве способа редактирования выберем "Ввод данных в поля форм"
Нажмем кнопку "Да, включить защиту" и в появившемся окне введем пароль защиты от редактирования.
Все!!! Теперь документ позволяет вводить поля формы, но запрещает напрямую менять остальной текст (при этом введенные данные могут быть любой длины - текст автоматически будет переформатирован под вводимые значения).
Как видите, ничего сложного или требующего специальных навыков нет (так что, закладка "Разработчик", скорее является потенциальным "пугалом", нежели отражает реальное состояние вещей). Однако, мы посмотрели только на одну составляющую электронных форм (или, точнее, на один из плюсов, выделенных нами), и совсем ничего не рассмотрели по части упрощения автоматической обработки текстов. Я обязательно расскажу и об этом, но так как данный материал требует уже определенных навыков программирования его я решил вынести в отдельную статью.
P.S. Те, кому приходилось работать с подобными механизами в Word ранее, наверняка заметят, что ничего принципиального нового я не рассказываю - внедрять в документы элементы управления ActiveX или вставить custom поля можно было и раньше.
Я с этим соглашусь, но замечу, что есть несколько "но", которые, по-моему, очень серьезно меняют расклад, а именно:
В отличие от старых ActiveX элементов, новые представляют собой части разметки, а потому у них нет проблем с их позиционированием внутри текста, чем очень страдали последние. Были, конечно, еще и встроенные элементы, но те, увы, обладали очень ограниченной функциональностью (т.е. обойтись без ActiveX было практически не реально).
Второй аспект связан с более общими изменениями в Microsoft Office, а имено переходом на основанный на xml (и опубликованный!) язык разметки и стандартные deflate-файлы в качестве контейнеров. Что это дает? В первую очередь, возможность извлечения и обработки данных форм без использования клиентского API самого Office или встраивания специальных макросов в документ.