Шаблоны документов и их наполнение из БД

← →
Desdechado © (2007-05-10 17:37) [0]

Хотелось бы поспрошать уважаемый public на предмет, кто как делает сабж.
Что интересует:
1. В каком формате хранится типовой документ (договор, наряд, счет, бланк)?
2. Как определяются места вставки внешней информации, характерной для конкретного экземпляра документа (ФИО, дата, объемы поставок, фамилии ответственных лиц, учетные номера)?
3. Есть ли для используемого вами формата специальные средства "от производителя редактора" для вставки такой информации в "болванку" документа?

Что хочется:
1. Есть "болванки" документов в БД. Есть некоторые данные, которые нужно впихивать в болванки.
2. Дать пользователю возможность вносить изменения в документ после заполнения болванки (например, приписать пару строчек), но заблокировать изменение взятых из БД полей.
3. Минимизировать труд программиста по созданию визардов заполнения болванок, однако оставить пользователю возможность работать с тем редактором документов, к которому он привык (в идеале - софт по умолчанию в системе для конкретного формата документов).

Понимаю, что можно использовать метки специального вида, внедренные в тело документа, однако в связи с тем, что документы пока неопределенного формата (DOC, XLS, XML, RTF, OO, etc), то и механизмы "пометки" и "начинки меток данными" весьма разные. Да и средства редактирования документов в формате XML (а не файлов с тэгами во всеобщее обозрение) пока не у всех есть.

И вообще, есть ли альтернатива меткам?
Кто что посоветует?

← →
tesseract © (2007-05-10 17:56) [1]

Вообще не "докУмент", а "печатная форма", ДоКумент по П.Печкину пенчать иметь должен. :-)

> 1. В каком формате хранится типовой документ (договор, наряд,
> счет, бланк)?

PDF ИМХО лучший. Изменить его проблематично (это важно!), ридер стоит почти везде.

> то и механизмы "пометки" и "начинки меток данными" весьма
> разные.

Почти везде есть механизм шаблонов. Для сохранения формат надо выбрать один (или в настройках) и не справшивать, чего юзер хочет. Поработай на техсаппорте поймёшь зачем.

← →
Desdechado © (2007-05-10 18:03) [2]

tesseract © (10.05.07 17:56) [1]
Под "типовым" документом я подразумевал как раз "болванку", которую помом автоматом начинять данными и давать для окончательной полировки юзеру. Поэтому PDF мне кажется здесь неудачным (или я чего не знаю?).

> и не справшивать, чего юзер хочет
Я и не собираюсь спрашивать. Я хочу использовать тот редактор, который у пользователя по умолчанию стоит (заранее выстроив админом иерархию "предпочтения", например: XML, если нет, то DOC, если нет, то RTF, если нет, то еще что-то). Естественно, это просто разноформатные версии одной болванки.

← →
PEAKTOP © (2007-05-10 18:12) [3]

>Что интересует:
>1. В каком формате хранится типовой документ (договор, наряд, счет, бланк)?
Все в формате Delphi *.xfm, который содержит шаблон QRepot-a. Для "текстовых" документов (договор, акт приема-передачи) - используется HTML.
>2. Как определяются места вставки внешней информации, характерной для конкретного экземпляра документа (ФИО, дата, объемы поставок, фамилии ответственных лиц, учетные номера)?
1) Для QReport-a - думаю, понятно.
2) В HTML используются тэги вида <%DataSetName.FieldName[:Format]%>, примитивный парсер, заменят их на поля наборов данных.
>3. Есть ли для используемого вами формата специальные средства
"от производителя редактора" для вставки такой информации в "болванку" документа?
1) Для QReport-a - дизайнер объектов похожий на делфячий.
2) SynEdit + TSynHighlighterHTML. Если юзер полез менять шаблоны (а, как правило, это сисадмин клиента), то хотя бы HTML он знает. Остальные, если не знают, нанимают тех, кто знает.

← →
Desdechado © (2007-05-11 11:19) [4]

PEAKTOP © (10.05.07 18:12) [3]
1. Не хотелось бы цепляться за внутренние форматы каких-то репортеров. Все-таки стандартное что-то более приемлемо.
2. Самоделки понятны, но надеюсь, что есть более универсальные средства.
3. Речь не о создании шаблонов, а об API производителя редактора, позволяющем более-менее автоматизированно заменять метки соответствующими данными.

← →
jack128 © (2007-05-11 11:29) [5]

Ну а чем Excel не устраивает? Кроме того, что он должен стоять у клиента. Насколько я помню отдельные ячейки мона запаролировать для изменнения. В качестве меток можно имена (names) использовать..

← →
Паша 1 (2007-05-11 11:31) [6]

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

← →
PEAKTOP © (2007-05-11 11:36) [7]

> 1. Не хотелось бы цепляться за внутренние форматы каких-то репортеров. Все-таки стандартное что-то более приемлемо.

А делфячий формат *.xfm уже не стандарт ? Я имею в виду, если шаблоны отчетов хранить во внешних файлах (или в БЛОБах базы данных), а не компилить статически. Но опять же, у меня по сути две машины отчетов: QReport и HTML-парсер. HTML-парсером пользуюсь исключительно для длинных "текстовых" документов, типа договоров страниц на 20.

> 2. Самоделки понятны, но надеюсь, что есть более универсальные средства.

Конечно, Macromedia Dreamweaver. А если хочеться что-то интегрированное с твоим ПО, то http://www.trichview.com, правда за него денег хотят.

> 3. Речь не о создании шаблонов, а об API производителя редактора, позволяющем более-менее автоматизированно заменять метки соответствующими данными.

Посмотри в сторону Microsoft DHTML-Editor, стоит на каждой NT, можно из делфей подцепить как ActiveX-Control.

← →
Desdechado © (2007-05-11 12:07) [8]

jack128 © (11.05.07 11:29) [5]
Я пока рассматриваю разные варианты в поисках лучшего/лучших. И пытаюсь узнать мнения коллег, особенно если они используют что-то в работе, а не предлагают гипотезы (хотя и они интересны).

Паша 1 (11.05.07 11:31) [6]
Безусловно, итог тоже надо хранить, однако вопрос пока в другом - в каком формате. Да и длинные договора в экселе редактировать как-то некузяво.

Про ворд/ексель уже писал, что он может отсутствовать на компе юзера. Но может присутствовать какой-нибудь OpenOffice или StarOffice, или CorelOffice, или банальный WordPad. Про версии я уже не говорю. Хочется гибкости.

← →
ANB © (2007-05-11 12:34) [9]

> Desdechado © (11.05.07 12:07) [8]

аська 285-340-244. Есть готовое решение - выгрузка в ворд из 1С. В виде DLL. Выкинуть лишнее (общение с 1С). Подсунуть нужное. К сожалению, мысля развилась только до одной таблицы в документе (в 1С 7.7 только одна таблица к документу и привязывалась, до 8.0 не доползли, но у нее своя работающая выгрузка оффис была).
Для экселя можно посмотреть афалину. Склонировать, как я прикидывал, не очень тяжело.
С опеном - х.з. Не пытался в него выводить, т.к. нашим клиентам это не нужно.

← →
roottim © (2007-05-11 12:49) [10]

ИМХО, чтобы работать со всем зоопарком, нужно взять что-то хорошее, шаблонное (типа FastReport), и сделать экспорты во все нужные документы..
Часть экспортов уже присутствует в фасте

← →
ANB © (2007-05-11 13:00) [11]

> и сделать экспорты во все нужные документы..

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

← →
Павел Калугин © (2007-05-11 13:32) [12]

> 1. В каком формате хранится типовой документ (договор, наряд,
> счет, бланк)?

отчет. Обычно - кристал.

> Дать пользователю возможность вносить изменения в документ
> после заполнения болванки

категорически нет.
Для этого есть БД с карточкой документа, с его текстом и т.д.

> Минимизировать труд программиста по созданию визардов заполнения
> болванок,

для отрисовки форм отчетов нужен не программист а обученая секретарша

> [2] Desdechado © (10.05.07 18:03)
> Поэтому PDF мне кажется здесь неудачным (или я чего не знаю?
> ).

главное - что в базе то и в тугаменте, а то у юзверей обычно ручонки так и чешутся не в базе править а сразу в отчете:)

> [5] jack128 © (11.05.07 11:29)
> Ну а чем Excel не устраивает?

Его юзверь злой может отредактировать. В результате данные в отчете не равны данным в БД.

← →
_uw_ © (2007-05-11 13:46) [13]

Desdechado © (10.05.07 17:37)

EkRTF специально для тебя.

← →
jack128 © (2007-05-11 15:25) [14]

Павел Калугин © (11.05.07 13:32) [12]
Его юзверь злой может отредактировать
файлы excel"я можно запаролить. К тому же возможность редактирование - одно из условий в [0]

← →
StriderMan © (2007-05-11 15:26) [15]

FastReport. шаблоны великолепно в блоб-поля сливаются.

← →
roottim © (2007-05-11 15:43) [16]

> Реализованные уже экспорты работают криво

FR как пример и никто не запрещает делать их самому..

А вообще должна быть в работе стандартизации (FR или Excel или еще что), а все что установлено там OOffice WorPad - должно в него конвертироваться!.
Только конвертер-то нормальный всеравно сложно написать(хотя можно), а писать шаблоны под каждую - тот еще гемор

зоопарк - не нужен.. нужен како-то НОЗ

← →
Desdechado © (2007-05-14 14:12) [17]

ANB © (11.05.07 12:34) [9]
Спасибо, постучусь.

roottim © (11.05.07 12:49) [10]
Павел Калугин © (11.05.07 13:32) [12]
Не хочется никаких репортеров использовать, т.к. слишком геморройно все это настраивать и поддерживать (формат разных версий у того же FR разный), да и экспорты у них корявые черезчур, проходили.

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

_uw_ © (11.05.07 13:46) [13]
Спасибо, посмотрел. Интересная штучка, однако все равно на репортер смахивает, но уже ближе. Жаль только, что Delphi only. Хотелось бы механизм и для C#. А то самому переписывать лениво, хоть и можно.

> FastReport. шаблоны великолепно в блоб-поля сливаются.
В блоб можно что угодно запхать. Только с этим "запханием" нужно как-то работать разными средствами, вот и хочется более-менее стандартные форматы.

> roottim © (11.05.07 15:43) [16]
Не думаю, что "конвертирование" - это хороший путь. При этом могут быть потеряны важные элементы форматирования и начинки документа. Причем весьма по-разному в зависимости от версий конверторов и целевых систем. Поэтому более осмысленным кажется создание нескольких версий шаблона (для разных целевых редакторов), которые бы заранее учли эти особенности и, например, вместо картинки-логотипа включали бы просто текст для тех редакторов, которые с картинками не дружат.

← →
keymaster © (2007-05-14 14:18) [18]

Я вордом пользуюсь.
Есть шаблоны документов с метками куда какое поле вставлять.
На основе шаблона создается новый документ.

← →
paul_k (2007-05-14 14:23) [19]

> хочется более-менее стандартные форматы

> Desdechado © (14.05.07 14:12) [17]
> слишком геморройно все это настраивать и поддерживать

Странно с CrystallReports гемороя не замечено. Установку кристал рантайм можно включить в свой клиентский дистриббутив и все.

> да и экспорты у них корявые черезчур

Какой экспорт кроме печати на ПДФ принтер, для отправки по мылу, нужен?

> Отчеты разные бывают, некоторые приходилось делать

Ключевое слово "некоторые", а в массе своей?

> хочется более-менее стандартные форматы.

по какому стандарту? точнее что есть стандартом в данном случае?

> Desdechado © (14.05.07 14:12) [17]
> ANB © (11.05.07 12:34) [9]
> Спасибо, постучусь.

Ну давай - стучись. Я сейчас в аське.

> paul_k (14.05.07 14:23) [19]

Клиенты частенько заказывают выгрузку отчетов в эксель. Особливо это любят аналитики, чтобы потом этими отчетами поиграть.

← →
paul_k (2007-05-14 15:03) [22]

> ANB © (14.05.07 14:28) [21]

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

> типовой документ (договор, наряд, счет, бланк)?

не так ли?
особенно учитывая, что данные для поигратся в Ёкселе очень легко отдаются через ДБФ

Desdechado © (10.05.07 17:37)

Уточни, что ты хочешь сделать.

Я пока ничего не понял.

Представим себе реляционную базу данных. В общем и самом простейшем случае она содержит справочники и накопители данных.

Если пользователь, "вводящий" документ, не будет иметь возможности выбора элемента из справочника, то он будет весьма озабочен, если не сказать больше.
А в ряде случаев пользователю понадобится и добавлять в справочник новые элементы. Обычные редакторы (такие как Word) вряд ли решат подобную задачу при помощи одних только "шаблонов". Так как эта задача принципиальная и дело не в выборе типа редактора, а в самой стратегии образования уникальностей в системе. Какова глобальность этих уникальностей, например? И каковы критерии уникальности для разного класса объектов? Например, будет ли иметь один и тот же ID товар с тем же наименованием, перемешивающийся на складе, но произведенный в разных странах или имеющий разные номера ГТД?

Вот, допустим, пользователю нужно создать счет-фактуру.
Он, как минимум, должен суметь выбрать фирму-контрагента. И выбрать его из справочника. Чтобы в базу данных заносился ID этого контрагента, а не текст (ООО Вася Ltd), набранный пользователем.

Можно попытаться, конечно, разработать интеллектуальную распознающую систему, пытающуюся на основе набранного пользователем текста, с учетом критерия максправдоподобия, подобрать в справочнике наиболее вероятного контрегента, которого пользователь имел в виду из числа ООО "Вася", ООО Вася и Вася Ltd.

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

К тому же сплошь и рядом фирмы имеют одинаковые или похожие наименования, а отличия проявляются в ИНН, адресе и прочих реквизитах. В ряде документов название фирмы и адрес, а также ИНН вводятся подряд, в одной строке. А вдругих - в отдельных "полях".

Вообще все, что касается первичных документов, все продумано крайне плохо еще на уровне стандартов.

Ряд документов, например, накладная ТОРГ12, на основе которой делаются начисления стоимости средств по факту "отгрузка", вообще не содержат ссылок на участников сделки ("продавец" и "покупатель"), а вместо этого содержат не имеющие вне договора самостоятельного юридического значения такие левые понятия как "грузоотправитель", "грузополучатель", "плательщик". Так как во времена СССР не существовало собственников.

И так на каждом щагу.

Вся первичная "нормативная документация" страдает невнятностью.

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

Однако как только мы пытаемся сделать автоматизированную бухгалтерскую проводку на основе входящего счета-фактуры, выясняется, что та дата, что указана в документе и является ее неотъемлемым реквизитом, не может служить датой начисления НДС к возмещению.

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

То есть в документе просто недостаточно информации для того чтобы на его основе вести финасовый учет.

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

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

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

Так что уточни, пожалуйста, для начала, как ты собираешься решать вопросы:

1. Идентификации объектов с целью уточнения их ID (товары, фирмы и т.д.) при их попадании в базу данных. Саму политику, так сказать.
2. Возможность пользователя выбирать из справочника или хотя бы прецедентов. Неужели у него ее не будет? А если будет, то как он будет синхронизировать свои "локальные прецедентальные справочники в шаблоне" со справочниками в "серверной базе", если в процессе ввода документа SQL-запросов к серверной базе не предполагается?

> kaif © (14.05.07 15:08) [23]
Ну ты и "копнул". Там, может быть, задача из предметной области таблицы на четыре... :))

> Вообще все, что касается первичных документов, все продумано крайне плохо еще на уровне стандартов.

А я вот люблю свою работу. Каждый день что-то "новенькое" ;))

perl + HTML::Template :)

paul_k (14.05.07 14:23) [19]
В roottim © (11.05.07 12:49) [10] речь, как я понял, шла о возможности выгрузки полученных на экране отчетов в разные форматы, которые мне нужны (DOC, RTF и т.п.). Так для FR они корявые, просто жуть.

keymaster © (14.05.07 14:18) [18]
Это понятно. Интересно не в 2 словах, а в деталях, как и что делается. Потому как идей масса, но не хочется очередной велосипед изобретать.

kaif © (14.05.07 15:08) [23]
Видимо, мы с тобой под термином "документ" понимаем несколько разные вещи. Для тебя документ - это сущность в БД, которая атрибутируется разными свойствами, заполняемыми разными работниками в меру своих должностных инструкций.
Для меня же - это просто печатная форма, так сказать, итог всей этой (или не этой) деятельности. Естественно, все данные для формирования этой бумажки уже есть в БД, же все заполнено компетентными лицами. А есть лицо, задачей которого - просто распечатать бумажку в нужный момент. Эта бумажка формируется автоматически из шаблона и тех ранее введенных (и размещенных по меткам в шаблоне) данных. Печатник может что-то еще с бумажкой сделать. Например, поля поменять или шрифт или пару строк дописать, которые забыли или не знали предыдущие деятели и которые не важны для делопроизводства, но важны для получателя бумажки (например, в наряде на работу вписать напоминание взять "антидог", т.к. работнику придется шагать по частному сектору с бродячими собаками).
Поэтому я и не освещаю тут способ заполнения документа данными и их появления в БД. Меня интересует только этап последний, печатный.
Т.е. по сути, ворд и прочие офисы для меня в этой задаче - это машина печати с возможностью минимальной правки перед этой самой печатью.

2 Desdechado © (14.05.07 15:45) [26]
Понял. То есть тебе нужна печаталка.

Я лично использую DDE-обмен с Excel (XLReport), так как в моем случае чаще фигурируют табличные данные.

Возможно, что Word был бы более подходящ, если основная масса печатаемых документов - договора.
Через COM работать с Word - одно удовольствие.
EkRTF- тоже неплохо.

Как-то пробовал xml-формат Excel.
Его понимает Office2003.
Очень неплохо получилось, надо сказать.

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

Если документы невелики по размерам, то, возможно XML-форматы Excel и Word были бы идеальны. Правда это требует присутствия на клиентских компьютерах Office2003.

← →
Gadenysh (2007-05-14 19:54) [28]

FR4 то что нужно.
и экспорты там значительно улучшились, я сам удивился (результат практически идентичен отчету в формате FR). И редактирование свое есть, коли приспичило.

а в самом ворде когда делал экспорт по шаблонам вручную - Find & Replace рулит - довольно прозрачно получилось - ищем в тексте вхождения типа
%%Customer.FirstName%% и подменям данными из датасета Customer итп.

Шаблоны документов и их наполнение из БД Найти похожие ветки