Сообщения № 1-2 выведены в отдельное обусждение отсюда.

mr_Smith_from_Matrix, спасибо за новую тему.

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

--

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

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

mr_Smith_from_Matrix, Вы об этом спрашивали?

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

Процесс:
1. Гражданин [1] обращается в некую организацию [2], которой нужна справка о составе семьи (например, за получение соц.помощи).
2. Организация [2] уже сейчас вводит данные о гражданине в свою ИС.
Сейчас организация требует от гражданина справку. А надо:
3. ИС организации [2] направляет запрос в паспортный стол [3] о предоставлении справки о составе семьи. Запрос направляется по электоронной почте или лучше даже синхронно по HTTPS в XML-документа.
4. Паспортный стол [3] отвечает организации [2] в виде XML-документа. ИС организации [2] парсит этот документ и сохраняет данные в БД ИС организации [2].
п.3-4 по возможности должны проходить в реальном времени, в течение максимум пары минут.
5. Если п.3-4 осуществляются в рельном времени, то сотрудник организации [2] тут же видит данные о составе семьи у себя на компьютере и продолжает работу с гражданином [1]. При этом сотрудник организации [2] вообще не знает как реально взаимодействуют [2] и [3]. Он работает только со своей ИС.

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

Вы же, видимо, предлагаете чтобы организация [2] отправляла в паспортный стол [3] графический файл в виде официального письма с запросом справки, а паспортный стол отвечал таким же графическим файлом. Но это сразу лишает возможности работы в реальном времени, т.к. графические файлы система обрабатывать не сможет в автоматическом режиме, их должен смотреть человек. Причем тут их 2 - один на стороне паспортного стола [3], другой - на стороне организации [2]. И вот тут-то каждый из этих сотрудников вынужен будет перебивать информацию с графического файла в свою ИС РУКАМИ!!! С точки зрения времени гражданина быстрее его вопрос решаться при таком подходе не будет хотя-бы потому, что его скорее всего будут еще раз звать в организацию [2] после того, как они получат справку.

Плюс ко всему, в моем варианте сотрудник организации [2] может даже не знать в какой паспортный стол надо направить запрос (это может быть паспортный стол хоть на другом конце страны) - все сделают информационные системы организации [2] и паспортного стола.

Боюсь Вас обидеть, но думаю, что предложенная Вами ситуация СЕГОДНЯ нереализуема в принципе. . Сегодняшние регламенты работы предложенных Вами организаций (

Я же предложил рассмотреть схему:

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

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

2. Не регламентируются вопросы идентификации организаций-отправителей с учетом неограниченного круга лиц, что не позволяет автоматически идентифицировать отправителя в системе-получателе (нужно использовать что-то из общедоступных реквизитов – ОГРН, ИНН, ОКПО и т.п.). Ведение реестра всех инсталляций систем документооборота (в заголовке предполагается указание идентификаторов таких систем) - это сродни ЕГРЮЛ и т.п. - не реально и не нужно.

3. Нет стандартизации типов и форматов файлов. Это означает, что системе-получатель без человека будет трудно обрабатывать вложенные "картинки". Более того, если одна организация отправит другой такой документ, где во вложении положит графический файл скажем формата Photoshop или даже PNG, то получатель может такой документ даже и не прочитать. Нужны хоть какие-то стандарты на вложения, хотя-бы для графических файлов.

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

5. Не предусмотрено атрибутов для хранения ЭЦП, при помощи которой подписан файл (а новые атрибуты добавлять запрещено). Таким образом декларация «Электронное сообщение в целом, так и составные его части, могут быть независимо подписаны электронными цифровыми подписями и/или зашифрованы» не выполняется.

6. В схему стандарта не вписывается большое количество документов, выпускаемых органами государственной власти, а именно очень часто скажем правительство РФ утверждает некие правила/инструкции/… Документ «Правила ….» сам по себе является самостоятельным документом, но утверждается он отдельным документом – приказом, постановлением правительства и т.д. Каждый из этих документов может иметь собственный номер/дату. Выпускаются в свет такие документы в связке, а передаются обычно совместно. В данном стандарте это по-моему не учтено, т.к. один XML-документ <= 1 юридический документ, а отправлять два и более связанных юридических документа в виде множества отдельных XML-документов неудобно. Коллизия вообщем.

7. Нет возможности указать/сохранить дату документа, дату вступления документа в силу, срок для реакции (ответа, акцепта).

8. Многая справочная информация не стандартизирована и не регламентирована (в рамках стандарта), например:
а) Не регламентированы хотя-бы общераспространенные виды документов (приказ, постановление, письмо и т.д.)
б) Почтовые адреса (тэг Address) не привязаны ни к каким классификаторам (например, к КЛАДР). Нет требований к написанию названий компонент адреса.

9. Не поддерживаются все типы адресатов (тэг Adressee, Author и др.), а именно – индивидуальные предприниматели и органы государственной власти. Индивидуальные предприниматели конечно являются физическими лицами, но все же взаимоотношения физ.лица как человека и физ.лица как предпринимателя несколько разные. Органы государственной власти, формально, юридическими лицами не являются, хотя и обладают практически всеми теми же гражданскими правами.

10. Не предусматривается система идентификации должностных лиц (нет ни одного реквизита, содержащего некий код/номер должностного лица).

11. Идентификация физических лиц осуществляется только по паспортным данным, хотя не у всех есть паспорта. Указание произвольного документа, удостоверяющего личность, не предусмотрено.

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

Радел (зону) "Задания" я пока не рассматривал.

Вообщем вот такие впечатления. Все, конечно, поправимо, но это будет уже другая версия стандарта.
К самому тексту стандарта есть по сути одна большая претензия - отсутствие XML-схемы для проверки валидности. Вот ЦБ РФ к своим стандартам ее делал и так было удобно...