Как приручить МКДО 2: Охота на подписантов

12 4

Пролог

Драконы бывают самые разные. Тоже самое и с трудностями в области МКДО - они могут возникнуть в самых разных областях. И для их решения используются, порой, кардинально разные приёмы.

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

Из прошлой статьи...

- Это было, честно говоря, довольно пугающе...
- Я тут для того, чтобы показать, что намного выгоднее и приятней дружить с МКДО, а не бояться его!
- Вздохнув и налив кружку кофе, я открыл справку и тем самым протянул руку навстречу новому миру – миру МКДО.
- МКДО – это модуль системы DIRECTUM, очень чувствительный к сертификатам и их актуальности. Чуть что – сразу начнутся ошибки.
- Некоторые ошибки могут не зависеть от вида документа и проявляться везде. Но даже у них есть похожее проявление, а значит главного злодея, стоящего за ними, найти и обезвредить труда не составит.
- Главное помнить – не надо страшиться нового. Пройдёт совсем немного времени, и сфера МКДО будет для вас родна и близка.
- На самом деле мир МКДО намного сложнее, больше и удивительнее, чем можно подумать.

Первый шаг -- оценка окружения

Оказавшись наедине с драконом в виде трудностей в подписании (или, и того страшнее, ошибкой при подписании), первым делом нужно не паниковать и понять - в какой обстановке всё произошло? На что нужно обратить внимание:

  1. Какой порядок подписания, и попадает ли он под стандартные кейсы, описанные в справке? Чаще всего система сообщает, что её пытаются использовать нетипично и не так, как это было задумано изначально.
  2. Понятен ли текст предупреждения/ошибки? Возможно, решение самое банальное и лежит на поверхности.
  3. Какая версия системы? В разных версиях системы работа с подписантами может отличаться, в этих случаях нужно сверяться со справкой.
  4. Были ли доработки в системе в области подписания, титулов и т.д.?

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

Частые ошибки и методы их решения

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

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

  • У пользователя есть действующий зарегистрированный сертификат для подписания документов. Согласитесь, сложно будет подписать документ сертификатом, которого у пользователя нет. 
  • Пользователь заведён в справочнике "Пользователи систем обмена", там же указаны самые актуальные данные по текущим сертификатам.
  • Если работа идёт с формализованными документами (УПД, счетами-фактурами и т.д.), пользователю должны быть выданы полномочия на подписание соответствующих документов.
  • Пользователь включён в список прав на подписание необходимых видов документов.
  • Пользователь указан в поле Подписант на карточке документа.

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

В поисках причин

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

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

Итак, что же делать в ситуации, когда нам нужно решение, а найти его самостоятельно не получается? Для начала попробовать поискать ответ в Базе знаний или Справке на свою версию. А также в разделах Вопросов и Идей, где можно в том числе самостоятельно задать вопрос или предложить новую идею по недостающей функциональности. Если же ничего похожего там не находится, а ответ нужен срочно -- нужно писать в техническую поддержку. Это самая последняя инстанция, куда можно обратиться и получить ответ. И не зря они являются последним рубежом в поисках помощи, ведь там находятся специалисты, которые решают любые вопросы -- от самых простых до самых сложных и запутанных, а их опыт измеряется сотнями непростых ситуаций, из которых они искали выход. Другими словами, если из ситуации есть какой-либо выход, то будьте уверены, что они его найдут.

Эпилог

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

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

А сталкивались ли вы с подобными проблемами, и как вы их решали? Ждём ваши рассказы и отзывы в комментариях! И не забывайте - именно от ваших предложений зависит, о чём будет (или не будет) следующая статья. 

Елена Питомцева

Если вам стало страшно от слова дракон МКДО, то для начала почитайте https://club.directum.ru/post/1140 

Антон Волков

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

Олег Андриянов

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

Олег Андриянов

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

Авторизуйтесь, чтобы написать комментарий