При работе в 1С:Управление нашей фирмой (УНФ) мы часто сталкиваемся с необходимостью корректировать данные документов. Одна из таких ситуаций возникает, когда требуется изменить автора документа. Например, если часть документов была введена одним бухгалтером, но теперь должна быть видна и принадлежать другому. Стандартные методы, такие как использование обработки "Групповое изменение реквизитов" для смены поля Автор, не всегда дают ожидаемый результат: документы меняют автора, но остаются невидимыми для него в списках. Разберем, почему так происходит и как правильно решить эту проблему, чтобы измененные документы стали доступны новому ответственному лицу.
Для начала, давайте глубоко рассмотрим, как устроены права доступа в 1С:УНФ. В конфигурациях 1С, особенно в современных версиях, таких как УНФ редакции 3.0, используется мощный механизм, известный как RLS (Row-Level Security) – безопасность на уровне записей. Этот механизм позволяет не просто разрешать или запрещать доступ к объекту (например, документу) целиком, но и ограничивать видимость отдельных записей или полей в зависимости от прав текущего пользователя.
Начиная с версии 1.6.25, в 1С:УНФ настройка прав унифицирована и соответствует привычному виду для типовых конфигураций. Права доступа в системе настраиваются через следующие элементы:
Именно RLS, встроенный в роли, играет ключевую роль в определении видимости документов. Мы можем изменить реквизит Автор в документе, но если действуют другие ограничения RLS, документ все равно не будет виден. Механизм RLS может ограничивать доступ по самым разным критериям: организациям, складам, кассам, группам контрагентов, проектам и даже по значениям некоторых полей самого документа. Поэтому простое изменение поля Автор не всегда достаточно, поскольку права доступа могут быть настроены на основе других реквизитов.
Как показывает практика и опыт нашего коллеги с форума, одной из наиболее распространенных и часто неочевидных причин невидимости документов является ограничение прав доступа по контрагентам. Рассмотрим подробнее эту ситуацию:
Представьте, что в вашей базе 1С:УНФ есть документы "Поступление в кассу", введенные одним бухгалтером. Вы, используя "Групповое изменение реквизитов", изменили поле Автор на другого бухгалтера. Однако новый бухгалтер по-прежнему не видит эти документы. Причина кроется не в поле Автор, а в том, что у нового бухгалтера нет прав доступа к контрагенту, который указан в этих документах. Например, контрагент может входить в определенную группу, к которой текущий пользователь не имеет доступа.
Решение, найденное нашим коллегой: В конечном итоге, выяснилось, что проблема заключалась именно в ограничениях на контрагентов. Бухгалтер, для которого документы должны были стать видимыми, не имел доступа к группе контрагентов, к которой относился контрагент, указанный в документе "Поступление в кассу". После предоставления прав на соответствующую группу контрагентов, документы стали доступны.
Таким образом, мы видим, что даже если пользователь указан как Автор документа, RLS-ограничения на связанные объекты (в данном случае, контрагентов) могут полностью блокировать видимость. Это критически важный момент, который необходимо учитывать при диагностике подобных проблем.
Помимо контрагентов, в 1С:УНФ существуют и другие объекты, по которым могут быть настроены RLS-ограничения, влияющие на видимость документов "Поступление в кассу". Разберем наиболее вероятные:
Документы "Поступление в кассу" напрямую связаны с конкретными кассами. Если у бухгалтера нет прав доступа к кассе, которая указана в документе, он не сможет его увидеть. Система может привязывать документы к кассиру через объекты КассаККМ или связанные с ними справочники. Каждый кассир, входя в программу, может получать доступ к торговому оборудованию через специальную запись подключения (элемент справочника), которая может быть уникальной для каждого. Это может создавать неявную привязку кассира к своим документам через объект КассаККМ.
Мы должны проверить:
КассаККМ, если он используется?ПодписьКассира или другие связанные с кассиром и кассовым оборудованием поля. Иногда, даже если поля кажутся пустыми, на их основе могут действовать фоновые RLS-ограничения.Хотя для "Поступления в кассу" это менее вероятно, но в других кассовых или банковских документах RLS может быть настроен по банковским счетам или складам (если документ связан с движением товаров). Всегда стоит проверять, нет ли ограничений на связанные объекты.
В случае с "Поступлением в кассу", поле "Принято от" также может играть роль. Оно может автоматически заполняться текущим пользователем, если активирована соответствующая настройка в "Мои настройки" - "Настройки пользователя", что может создать видимость привязки к пользователю, хотя основное ограничение по RLS может быть на другом объекте.
В процессе обсуждения на форуме возник вопрос о поле "Ответственный". Давайте выясним его значение и применимость:
Поле Ответственный не является универсальным реквизитом для всех документов в 1С. Его наличие зависит от конкретного вида документа и логики конфигурации. Например, в 1С:Бухгалтерии Предприятия (БП) поле Ответственный в большинстве документов, как правило, заполняется пользователем системы. Однако в 1С:УНФ подход иной: поле Ответственный чаще связано с элементом справочника Сотрудники, а не напрямую с объектом Пользователи информационной базы.
В нашем конкретном случае, при анализе документа "Поступление в кассу", выяснилось, что у него нет стандартного поля Ответственный. Это означает, что мы не можем использовать этот реквизит для решения проблемы видимости, и поиск причины должен быть сосредоточен на других механизмах RLS.
Однако, если бы речь шла о другом документе, где поле Ответственный присутствует, его видимость можно было бы настроить в параметрах пользователя и прав, установив или сняв флажок "Отображать автора документов". Назначение ответственного лица может быть связано с различными типами документов и операций, например, в заказах, заявках или актах выполненных работ, где требуется указать менеджера или исполнителя.
Когда мы сталкиваемся с проблемами видимости документов, даже после изменения ключевых реквизитов, нам необходимо провести комплексную диагностику. Вот шаги, которые мы рекомендуем предпринять:
В первую очередь, мы должны тщательно проверить все настройки прав доступа для пользователя, который не видит документы. Необходимо убедиться, что у него есть все необходимые права на следующие объекты, которые могут быть связаны с документом "Поступление в кассу":
Мы должны последовательно пройтись по всем этим точкам контроля RLS, сравнивая права "видимого" бухгалтера с правами "невидимого".
Когда стандартными средствами не удается найти различия, на помощь приходит консоль запросов. Мы можем написать запрос, который выводит все реквизиты видимых и невидимых документов, а также связанные с ними справочники (контрагенты, кассы, организации). Сравнивая результаты, мы сможем выявить, по какому полю или связанному объекту есть расхождения в данных, которые могли бы быть причиной ограничения RLS.
ВЫБРАТЬ
ДокументПоступлениеВКассу.Ссылка,
ДокументПоступлениеВКассу.Дата,
ДокументПоступлениеВКассу.Номер,
ДокументПоступлениеВКассу.Автор,
ДокументПоступлениеВКассу.Контрагент,
ДокументПоступлениеВКассу.Касса,
ДокументПоступлениеВКассу.Организация,
ДокументПоступлениеВКассу.СуммаДокумента,
ДокументПоступлениеВКассу.Комментарий,
ДокументПоступлениеВКассу.Проведен
ИЗ
Документ.ПоступлениеВКассу КАК ДокументПоступлениеВКассу
ГДЕ
ДокументПоступлениеВКассу.Ссылка В (&СписокНевидимыхДокументов)
// Для сравнения можно выполнять два запроса или добавить условие по пользователю
Такой анализ поможет нам увидеть "скрытые" различия, на которые действует RLS.
После любых изменений в правах доступа, профилях или группах, а также после изменения данных, на которые распространяются RLS-ограничения, иногда требуется "пересчитать" права или обновить информационную базу. В некоторых случаях это может быть сделано автоматически, но иногда может потребоваться принудительное обновление кеша или даже рестарт сервера 1С:Предприятия. Проверьте соответствующие регламентные задания или служебные обработки, которые могут отвечать за актуализацию прав доступа.
Журнал регистрации 1С — это ценный инструмент для диагностики. Мы можем использовать его для отслеживания действий пользователей, изменений в данных и возникших ошибок. Если при попытке доступа к документу возникают ошибки, связанные с правами, они будут зафиксированы в журнале регистрации, что поможет нам быстрее определить источник проблемы.
Если в вашей базе включено версионирование объектов для документов "Поступление в кассу", мы можем просмотреть историю изменений документа. Это позволит нам увидеть, кто и когда вносил изменения не только в реквизит Автор, но и в другие поля, такие как контрагент или касса, что может дать подсказки о причинах блокировки доступа.
Если документов немного и они не имеют сложных взаимосвязей с другими объектами учета, можно рассмотреть вариант их пересоздания. Мы можем пометить "проблемные" документы на удаление, а затем создать их заново уже от имени нужного бухгалтера и с правильными правами доступа. Однако, этот подход следует применять с осторожностью, так как он может повлиять на хронологию учета и требует внимательной проверки всех последствий.
В случае ошибок в прошлых периодах, вместо прямого изменения, иногда более корректным с точки зрения учета является создание корректирующих документов.
В итоге, мы убедились, что изменение реквизита Автор в 1С:УНФ – это лишь часть задачи по передаче ответственности за документ. Критически важно глубоко понимать механизмы RLS и проверять все связанные объекты на наличие ограничений прав доступа. Только комплексный подход и тщательная диагностика позволят нам эффективно управлять видимостью документов в системе.