bengunnVad72я написал хтмл, так как понимаю, как это сделать (выдать хтмл-код клиенту броузер, где для редактирования оставить только нужные поля). Если это можно сделать с PDF сразу, выдать в браузер pdf для редактирования, то я не против. Хотя ... Мне же потом придется, после подписания документа клиентом, делать парсинг этого документа для формирования своего счета (документа) этому клиенту, но уже со своей подписью (это все должно делаться автоматически).

ну вот ту страницу, что пользователь в браузере видит, со всеми своими формами, параметрами форм, скриптами и т.д. лучше не считать документом, а толкнуть (например ajax-ом) форму с введенными данными на сервер, где сформировать реальный документ и вернуть клиенту для подписи.+1
Все поля после заполнения сразу сохранить в БД (зачем что то потом парсить?), на основе этой информации сгенерировать пдф (полно готовых инструментов), этот пдф тоже сохранить и дать клиенту его скачать. И потом сохранить подпись, что пришлет клиент. И все - никаких сложных телодвижений. А как именно клиент подпишет пдф - его дело. Хотя можно ему дать ссылки на разный софт для подписей.

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

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

Цель достигнута.

Vad72
P.S. Мне одному кажется, что решение что-то скачивать, сохранять, заполнять, подписывать какой-то программой, а потом загружать подписанный файл(ы) на сайт, это какой-то позавчерашний день?
Позаввчерашний
но - решение ДОЛЖНО быть универсальным.
Плагин к браузеру может быть, а может и не быть - и у пользователя должна быть возможность работать в любом случае.
Более того, почитайте про EDI, и подумайте, как вписывается плагин к браузеру (намек - никак е вписывается).

А заполнять - это совсем плохо.
Никаких заполнений в документе.
я об этом уже говорил.
заполнили на сайте (желательно создать еще и API - тот же REST не особенно сложен), получили документ, подписали, отправили подпись.

и если жестко настраиваться ТОЛЬКО на плагин в браузере - не будет нужной гибкости. да и сроки. без плагина все можно сделать за пару недель. и запустить. а потом доделывать плагины и прочие украшательства.

Vad72s_ustinov не будет нужной гибкости
а что за гибкость?
...
Заполнение в документе - это я написал как будет воспринимать пользователь. Он вообще не должен понимать всех этих тонкостей. Он должен создать документ по шаблону, заполнить необходимые поля, сохранить, подписать.
например - какой браузер? ОС?
тот же хромбук будет работать?
какой именно софт для подписей? только один вид (медок)?
будет ли возможность отсылать / получать подписанные документы без участия человека (автоматом с 1С / сапа / прочих прог)?
Работать с системой через емаил?

это все называется - гибкость.

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

Vad72 какой именно софт для подписей? только один вид (медок)?
только один медок, так как эти "медки" не понимают сейчас друг друга. Как это побороть?
А зачем им понимать друг друга?

Проблемы на самом деле нет. Просто вы слишком сильно "углубились".

Vad72 будет ли возможность отсылать / получать подписанные документы без участия человека (автоматом с 1С / сапа / прочих прог)?
спасибо за вопрос!, это очень важно на самом деле. С нашей стороны, подписанные документы будут отрабатываться автоматически без участия человека. А вот клиенту, нужно было бы предоставить так же такую возможность, особенно, если у него есть всякие автоматизированные системы.

это называется EDI.

Еще раз повторю - вы воспринимаете проблему не под тем углом, слишком углубляетесь в детали.

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

еще раз:
1. сперва надо заполнить данные в базе (не поля в документе, а именно запись в базе данных) - количества, суммы, сроки и прочие условия. доступ с помощью веб странички, где ручками заполняются поля - только ОДИН ИЗ ВАРИАНТОВ создания записи в БД.
2. на основе данных в БД формируем документ (например ПДФ или другой), который можно скачать / отослать. опять же, можно скачать или отослать автоматом с помощью программы. этот документ может иметь как челевеческую форму (пдф), так и машинную (хмл или подобное - читаем про стандарты - http://www.gs1.org/gsmp/kc/ecom - все придумано до нас)
3. принять / отправить подпись. подпись - это просто файлик определенной длинны. и всё!!! на этом уровне абстракции все программы для подписывания абсолютно совместимы между собой

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

и не нужно за людей думать, каким им браузером (плагином) пользоваться
все равно они или сами поймут (по инструкции с картинками), или позовут "программиста"

Vad72s_ustinovВам что нужно?

Задача минимум:
1. Чтобы клиенты не носили документы к нам в бумажном виде с подписью директора и покрой печатью.
2. Чтобы третья сторона выступала в суде с доказательством, что данный документ был отправлен таким-то клиентом в такое-то время.

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

Почитайте, что такое ЭЦП. И как именно некая ЭЦП становится такой, что документ с ней можно нести в суд (центры выдачи ключей и прочее).


Центров выдачи ключей - несколько. Софта для ЭЦП - несколько. Более того, с одними и теми же ключами может работать РАЗНЫЙ софт.

А вдруг вам придется работать с зарубежными партнерами, у которых свои ЭЦП?

Поэтому я и говорю, что влазить в то, как именно формируется ЭЦП - не надо. И придумывать плагины - тоже не надо.

Есть фирмы, которые пишут софт для ЭЦП. И не надо делать чужую работу.

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