Какие проблемы могут возникнуть, если пользователям предоставить права редактирования в 1С?

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

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

1. Изменения параметров документа вручную. Встречаются случаи, когда бухгалтера самостоятельно устанавливают номер документа вне установленного алгоритма нумерации. К примеру, если проставить максимальный порядковый номер документу вручную (к примеру, Д-9999999), то другие пользователи просто не смогут создать новый документ. Еще хуже, если будет поставлен номер близкий к концу исчисления, но не последний. Тогда виновника и источник ошибки будет найти гораздо сложнее, да и все введенные после него документы будут в закрытом периоде. 
2. Редакция элементов справочника. По разным причинам, в том числе и самым абсурдным вроде изменения названия в шапке документа, пользователи самостоятельно редактируют элементы справочника (наименования, адреса, платежные реквизиты и т.д.). Тут важно понимать, что для учетной системы ТЦ «Олимп» (к примеру) и Торговый Центр «Олимп» - это два разных элемента. И любое самостоятельное исправление элементов справочника вызовет лавину последствий. Во-первых, из-за того, что элементы разные, перестанет корректно работать сортировка, поиск и формирование отчетов. Во-вторых, если реквизиты будут внесены с ошибкой, это приведет к созданию недействительных документов впоследствиив последствии. Ну и представьте, если вдруг неправильно будут введены платежные данные, к каким это может привести последствиям.
3. Сложные многоуровневые фильтрации. Некорректная работа с динамическими списками может сильно замедлить работу информационной базы. Если перед работником, к примеру менеджером, поставлена задача найти всех клиентов компании по трем-четырем параметрам (статус операции, сумма, дополнительные условия и т.д.), то менеджер просто пойдет отбирать список по заданным параметрам. И если для сортировки нужно обработать небольшое количество операций, то система такую нагрузку даже не заметит. Но что если операций сотни тысяч или миллионы? Что если всю эту информацию нужно сортировать по 6-7 и более параметрам одновременно? А что если это такие изощренные сортировки будет делать не один пользователь, а сразу несколько? В таком случае ресурсов сервера может попросту не хватить. Система может сильно «тормозить» или даже перестать отвечать. Но хуже всего, если такие незавершенные операции будут копиться в автозапуске, и повторно нагружать систему при каждом новом сеансе.
4. Универсальный отчет. Еще один пример некорректного использования динамических списков. Когда перед работником стоит задача сделать нестандартный отчет, который не был предусмотрен на этапе внедрения конфигурации, он опять же обратится к функции динамических списков и выгрузит всю отсортированную информацию в Excel. Если при этом был задан «тяжелый» многоуровневый запрос, то на производительности системы это скажется не лучшим образом. Более того, когда речь идет о большом объеме данных, такая выгрузка может привести к увеличению сеансовых данных, вплоть до использования всего места на диске.
5. Множественные сеансы. По разным причинам пользователи могут создать сразу несколько рабочих сеансов в системе. К примеру, нужно сформировать тяжелый отчет или сделать сортировку по сложному запросу. В таких случаях пользователи часто открывают дополнительные сеансы, чтоб тяжелые задачи выполнялись системой в фоновом режиме. И мало того, что это очень создает дополнительную нагрузку на сервер и базу данных, так еще и может привести к многочисленным рабочим ошибкам, несовместимости действий в разных сеансах, ошибкам лицензирования и многим другим проблемам.
6. Использование сторонних внешних отчетов и обработок без согласования. Использование сторонних решений, особенно скачанных из непроверенных источников может привести к самым непредсказуемым последствиям.  Поэтому доступ пользователей к открытию внешних отчетов и обработок из файлов – очень опасная вещь, которую нужно закрывать еще на этапе внедрения конфигурации.
7. Полные права на редактирование. Причем не обязательно у всех. Достаточно только, чтоб Главный бухгалтер в прошлом имел опыт программирования или работал консультантом. Эта ситуация будет схожа с двумя «хозяйками» на кухне. И дело даже не в компетентности, самовольные изменения в конфигураторе могут привести к целому ряду ошибок и программных конфликтов. Поэтому доступ к конфигуратору лучше не давать никому.

Все эти проблемы имеют два решения. Первое – квалифицированные работники, которые хорошо понимают механику работы 1С и последствия своих действий (что очень близко к утопии), или максимальное ограничение прав пользователя в системе. Еще на этапе разработки программисту стоит задуматься об ограничении прав и других методов «закручивания гаек» для работы пользователей. Начиная от всех запретов на внесение изменений вручную, заканчивая ограничениями на использование сложных и ресурсоемких функций.

Цена ошибки – простой в работе 1С. При этом, не всегда проблему получится решить простым восстановлением из копии, в определенных случаях может потребоваться участие эксперта для исправления ситуации. 

Многие руководители начинают задумываться о безопасности системы и правах доступа только после серьезных ошибок и простоев. Исключите вероятность сбоя в системе по вине пользователей.

Получите бесплатную консультацию по оптимизации работы вашей конфигурации 1С от специалистов Meta, оставив заявку на нашем сайте или по номеру 0 (22) 857-157.