Задача, в общем-то не сложная.
В организации есть куча всяких регламентированных документов, которые надо периодически заполнять, печатать подписывать и т.п. Речь не о бухгалтерских бумагах, они более-менее стандартные, и та же 1С с этим делом справляется. 
Речь о документах которые регламентированы в рамках организации. От договора купли-продажи, до служебки на предоставление отпуска или отгула. 

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

Как это видится в реализованном виде. Пользователь заходит на сайт, логинится. Выбирает необходимый документ. Пусть это будет заявление на предоставление отпуска. Пользователь вбивает свои данные в отведенные поля, ФИО, даты, и т.п.
Выбирает тип отпуска (очередной, внеочередной, по уходу за ребенком и т.п.) Лготный/не льготный, ну и всякие другие параметры чего он там хочет от отпуска. Нажимает кнопку и получает .doc файлик, который печатает подписывает и несет куда надо. Сервер, тем временем запоминает данные сотрудника и хранит их. 

Затем разработчики делают титанические усилия, и добавляют в сервис документы необходимые для оформления командировки. Тот же пользователь заходит, на сайт, логинится. Теперь его послали в командировку, и он хочет заполнить документы через сайт, прошлый раз ему понравилось. ФИО его подставляется автоматом, так как он уже был на сайте, и эти данные где-то там хранятся. Но в новом документе есть и другие поля, которые пользователь еще не вносил. Например свой табельный номер, название подразделения где он работает и другая хрень важная информация.
Он ввел все параметры командировки, галочками выбирает какие документы по командировке ему нужны: заявка на аванс, командировочное задание, командировочное удостоверение, приказ, бланк регистрации в гостинице и т.д., жмакает на кнопку и получает .zip архив в котором все те же .doc файлы. Печатает, подписывает, уезжает.


Собственно вот такой сценарий. Проблема в чем, что заранее не известно какие документы будут ложится в сервис. Т.е. да сегодня сделали 10 шаблонов, а завтра из головного офиса прислали еще пять регламентированных бланков для сейлзов. А послезавтра все отчетные бланки финансистов поменяли на такие же, но другие. В общем, нужно как-то гибко добавлять/изменять/удалять шаблоны в системе. При чем, та информация которая уже введена пользователем должна сохраняться. Т.е. если пользователь один раз ввел свой табельный номер для одного шаблона, то этот ТН в следующий раз в другом шаблоне должен уже подставится автоматом (конечно с возможностью исправления).

Задача - выбрать подход, каким образом лучше реализовать данный сервис.
Любые предложения, замечания, критика и просто размышления на тему - категорически приветствуются!

А сайта ваще никакого на даный момент под это дело нету?
Можно сделать так чтобы человек, добавляющий новый шаблон, указывал какие поля в нём есть. Все поля будут типа string чтобы не иметь проблем. Юзеры всё равно не будут утруждаться писанием регулярных выражений или масок или ещё чего чтобы ограничить вводимые значения.

Добавлено через 48 секунд
Или кто шаблон делает этот? Может есть возможность автоматически определять необходимые вводимые поля? Тем лучше юзеру.

Нет, пока нет.


В принципе, да, можно.  Но скорее всего, это далекая задача. На данном этапе нужно максимально облегчить работу администратору (программисту) - функции создания/исправления/удаления шаблонов. 

Основной вопрос, как организовать хранение информации. Сегодня нам достаточно только ФИО работника, завтра понадобится его ИНН, послезавтра адрес, а затем дата рождения. 

Другой вопрос как лучше реализовать бизнес логику для шаблона. 

Вопросов много. 

Вы ж всё равно шаблоны в ворде делаете, так? Дык храните их как файлы и не имейте проблем.

Я бы юзал StringDictionary. В ASP.NET есть такая штука как профили, можно использовать её. Ещё можно хранить данные в БД в одной колонке сериализировав их в xml или в bin. 

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

Я правильно понял идею?

Почему бы не хранить рядом с шаблоном xml-файлик, в котором была бы вся необходимая инфа о шаблоне и данных используемых в нем? Пусть его имя будет равно имени шаблона плюс '.xml' (template.doc.xml).

А еще, чтобы облегчить себе жизнь и скорость выполнения можно перейти на офисный OpenXML-Format. На сайте майкрософта где-то можно скачать бесплатный фреймворк для работы с Office2007 форматом. С его помощью можно гораздо более удобно работать с файлами 2007-ого офиса.

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

После заполнения документа, чтобы не хранить его на сервере целиком, можно запоминать данные в БД в общей таблице, например в такой:
Documents (ID, TemplateID, ....)  - одна запись в ней это один заполненный кем-либо документ
DocData (DocID, DataName, DataValue)   - одна запись соответствует одному заполненному полю в шаблоне.

Для хранения всего остального можно сделать например так:
Templates (ID, FileName, Type, ...)    - одна запись это информация об одном шаблоне.

Пользователей можно хранить так:
User (ID, Login, Password, XMLUserInfo)   - уникальная запись на одного пользователя сайта

либо так:
User (ID, Login, Password)   - уникальная запись на одного пользователя сайта
UserInfoProps (ID, PropName)   - PropName - это имя свойства данных, например FIO или BirthDate
UserInfo (UserID, PropID, Value) 

Это все на вскидку, насколько это все удобно и рабочее решать тебе.

Спасибо, я тоже склоняюсь к этому варианту.


К сожалению, пока OpenXML не стал стандартом де-факто, пользователя не заставить пользоваться удобным мне форматом. Как опция - не вопрос, согласен. Но делать выдачу только в OpenXML, еще не время.


Тогда все данные должны быть только строковые. Мне кажется, что это не очень хорошая идея. Конечно в данном примере работа со строками - основная работа, но все же нужен еще и int и date да и double пригодится. Или хранить все данные  как в строку, а для обработки парсить в нужный тип?

Картина постепенно проясняется.

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

Альтернативой этому мог бы быть все тот-же XML-формат сохраняемый в БД.

Либо можно сохранять инфу об использованных идентификаторах (UserID, TemplateID, someID....), чтобы можно было повторно вытащить инфу для ранее выписанного документа, но в этом случае возникает вопрос сохранности данных во времени. Сотрудника могут удалить из БД, и тогда документ выписанный им ранее не сможет быть восстановлен. Для работоспособности этого варианта, необходимо будет отказаться от удаления записей из БД вообще и использовать везде дополнительное поле IsDeleted, и соответственно все запросы должны будут учитывать это поле, что неизбежно приведет к неоправданной сложности кода и работы с БД.

То есть первые два варианта, пока выигрывают до тех пор, пока не будет предложен еще.


Никогда не будет время, если думать об этом. Офис вышел два года назад. Я знаю людей, которые на 2000 винде до сих пор работают, так что же теперь, не писать на C# из-за них?

Еще, я бы подумал в сторону PDF-формата или XPS. Думаю будет лучше предоставить пользователю документ, пртгодный только для печати, а не для редактирования тоже. Или вообще HTML'ом рисовать, тогда и заполнять будет удобнее. Кстати XPS очень не плохой формат, но он тоже, вроде еще не де-факто.

Прелесть хранения данных в том, что их можно использовать повторно. Если данные из нужного формата уйдут в стринг, то повторно их уже не сможешь использовать. 
Поэтому пока остановимся на ХМL в БД.


Ну, если они заказчики и не могут поставить .нет или висту, то да. Либо не беремся за работу, либо делаем так чтобы работало у заказчика.  (Хорошо еще что на линуксе не сидят).


Это office tools? Или что то другое?

 
Категорически не согласен. Это его, пользователя документ, и он имеет право делать с ним что хочет (нужно). В конце концов пользователь отвечает за конечный вид документа. Если запретить правку, то отвечает сервис. Зачем лишняя ответственность?   

нет, это OpenXML SDK v.2



Твои данные пусть хранятся как положенно, в других таблицах. Эту таблицу я предполагал использовать как штамп данных на момент составления документа. То есть, если необходимо, чтобы документ можно было вытащить с сервера через 10 лет, и чтоб он находился в том состоянии в котором его выписали, то нужно либо сохранить сам документ, либо сделать штамп данных на основе которых он был выписан. Штамп данных будет занимать меньше места на сервере, нежели весь документ. Единственное, что нужно выполнить для работоспособности этого варианта, это не удалять никогда шаблоны. Если шаблон нужно изменить, то он добавляется и становится шаблоном по умолчанию, а старый перестает быть доступным для пользователя, и доступен только для пересоздания ранее выписанного документа.

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

Все, теперь понял идею.