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

Пролог

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Эпилог

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

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

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