На личном опыте, при работе с Docsvision, часто акцентирую внимание на допущенную при проектировании решения ошибку. Этот нюанс, создаст неприятные проблемы на этапе обновления платформы в дальнейшем. Вам будет казаться, что проект удался, сэд сдана в эксплуатацию и беспроблемно выполняет необходимые задачи. Пройдет время и кому-то выпадет приз, в виде обновления платформы, с учетом базовых модулей. Здесь то и произойдет знакомство с ошибкой, под названием «Ошибка уникальности», но об этом попозже, а пока познакомлю или напомню, что же входит в состав системы Docsvision.

То, что отображено на схеме, относится к базовым модулям Docsvision, которые содержат функциональность, что обеспечивает работу сэд в целом.
Рассмотрим пример на приложении «Управление документами» , но проблема характерна и для объектов других модулей, например, конструктор согласований или базовые объекты.
Приложение «Управление документами» добавляет в Docsvision типовую реализацию электронного документооборота организации и функции для работы с договорами.
При установке модуля, в систему будут загружены следующие данные:

• Виды карточек;
• Роли;
• Папки;
• Группы сотрудников;
• Данные конструктора состояний;
• Данные конструктора разметок;
• Данные конструктора ролей;
• Данные конструктора справочников;
• Данные конструктора нумераторов;
• Бизнес-процессы;
• Скрипты карточек;

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

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

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

Наступает день обновления, происходит установка новых модулей, загрузка конфигурации в базу данных и упс, возникают ошибки, например:

• Нарушается уникальность атрибутов внутри записей секции. Запись с уникальным значением атрибута уже существует.

• Указанный ключ уже используется.

Текст ошибки может быть изменен, в зависимости от установленной локализации операционной системы.

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