Как вернуть поле "Подразделение" в Расходный кассовый ордер (РКО) в 1С:Управление торговлей после обновления?

Программист 1С v8.3 (Управляемые формы) 1С:Управление торговлей Управленческий учет Торговля и дистрибуция
← На главную

После очередных обновлений конфигурации 1С:Управление торговлей (УТ) до версий 11.5.17.183 - 11.5.21.116, пользователи столкнулись с проблемой исчезновения поля "Подразделение" из формы Расходного кассового ордера (РКО) при выборе операции "Выдача в другую кассу". При этом для других типов операций в РКО поле "Подразделение" остаётся видимым и доступным. Это изменение, на первый взгляд незначительное, приводит к серьёзным затруднениям, особенно у организаций, где активно используются механизмы разграничения прав доступа на уровне записей (РЛС) по подразделениям. Давайте вместе разберемся в причинах этой ситуации и найдем эффективные способы её решения.

Анализируем причины исчезновения поля "Подразделение"

Прежде всего, давайте выясним, почему разработчики могли убрать поле "Подразделение" из формы РКО для операции "Выдача в другую кассу". Вероятно, это связано с изменением логики работы системы и стремлением к упрощению ввода данных, а не с ошибкой конфигурации. Рассмотрим подробнее возможные мотивы:

  1. Изменение логики привязки кассы к подразделению: В системе 1С:Управление торговлей кассы предприятия, как правило, привязаны к определенным подразделениям. Для подразделений, которые не выделены на отдельный баланс, всё равно предусмотрена возможность формирования отдельных кассовых книг. Таким образом, при выборе конкретной кассы-получателя в операции "Выдача в другую кассу", система может автоматически подразумевать и соответствующее подразделение. Это делает отдельное поле "Подразделение" на форме избыточным, поскольку выбор кассы уже определяет принадлежность операции к определенной хозяйственной единице. Мы можем предположить, что разработчики посчитали это поле дублирующим и убрали его для упрощения интерфейса.
  2. Потенциальная путаница и ошибки ввода: Если бы поле "Подразделение" оставалось на форме, пользователи могли бы случайно выбрать подразделение, не соответствующее выбранной кассе-получателю. Это привело бы к несогласованности данных в различных регистрах учета. Например, денежные средства могли бы пройти по активам/пассивам для подразделения, привязанного к кассе, а по регистру движений денежных средств — для ошибочно выбранного подразделения. Устранение дублирующего поля помогает избежать таких расхождений.

Итак, с точки зрения логики "чистой" типовой конфигурации, удаление поля могло быть осознанным решением. Однако на практике это привело к новой проблеме.

Основные последствия: конфликт с правами доступа (РЛС)

Главная сложность, возникающая из-за отсутствия поля "Подразделение" в РКО, проявляется в работе механизмов разграничения прав доступа на уровне записей (РЛС). Многие организации используют РЛС для ограничения прав пользователей строго по подразделениям. Например, сотрудник может иметь право проводить документы только для своего подразделения и видеть только свои данные.

Когда поле "Подразделение" отсутствует в РКО с операцией "Выдача в другую кассу", система не может явно определить, к какому подразделению относится данный документ. Если у пользователя настроено ограничение по подразделениям и операция не содержит явного указания на разрешенное ему подразделение, он получит ошибку "Недостаточно прав доступа" при попытке провести такой документ. Это происходит даже в тех случаях, когда фактическая операция выдачи денежных средств из одной кассы в другую происходит внутри разрешенных ему подразделений или между ними.

Мы видим, что, пытаясь упростить интерфейс и избежать дублирования информации, разработчики непреднамеренно создали конфликт с существующей бизнес-логикой контроля доступа.

Несогласованность в заполнении регистров

Дополнительный аспект проблемы, который мы должны проанализировать, связан с заполнением регистров накопления. В последних версиях УТ 11.5 был добавлен новый реквизит "Подразделение" в регистр ДенежныеСредстваНаличные. И здесь обнаруживается интересная несогласованность:

  1. Приходный кассовый ордер (ПКО): При операции "Поступление из другой кассы" (являющейся парной к нашей "Выдаче в другую кассу") ПКО корректно заполняет реквизит "Подразделение" в регистре ДенежныеСредстваНаличные, основываясь на подразделении кассы-получателя.
  2. Расходный кассовый ордер (РКО): Для операции "Выдача в другую кассу" РКО не заполняет реквизит "Подразделение" в том же регистре ДенежныеСредстваНаличные.

Эта асимметрия в заполнении регистра накопления является недоработкой типовой конфигурации. Она усугубляет проблемы с РЛС и может привести к некорректной аналитике по движению денежных средств в разрезе подразделений. Без явного указания подразделения в РКО, информация о движении денежных средств "выпадает" из детализированного управленческого и бухгалтерского учета по подразделениям, что критично для компаний с жесткой структурой контроля.

Эффективные решения проблемы

Теперь, когда мы полностью понимаем суть проблемы и её последствия, давайте рассмотрим конкретные шаги по её устранению.

1. Возвращаем поле "Подразделение" через расширение конфигурации

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

Разберем по шагам, как это можно реализовать:

  1. Создание расширения и заимствование объектов:

    Для начала, мы создаем новое расширение. Затем нам потребуется заимствовать форму документа Документ.РасходныйКассовыйОрдер.ФормаДокумента, а также сам документ Документ.РасходныйКассовыйОрдер, чтобы добавить в него необходимые реквизиты, если это потребуется (хотя чаще всего реквизит уже есть в объекте, но не выведен на форму или не заполняется).

  2. Добавление поля на форму:

    На форме документа нам нужно будет добавить новое поле. Если реквизит Подразделение уже существует в документе, но скрыт, мы просто сделаем его видимым. Если реквизита нет, то нам придется добавить его в объект Документ.РасходныйКассовыйОрдер через расширение, а затем уже вывести на форму. Предположим, что реквизит существует, но был убран с формы для операции "Выдача в другую кассу".

    Мы найдем группу элементов формы, в которую хотим добавить поле, например, рядом с выбором кассы или в группе основных реквизитов. Создадим новый элемент формы типа "Поле ввода" и свяжем его с существующим реквизитом Подразделение документа.

    Важный момент: Мы должны обеспечить видимость этого поля только для операции "Выдача в другую кассу". Для этого мы можем использовать обработчик события ПриИзменении для поля "Операция" (или "ВидОперации") на форме, либо устанавливать видимость поля в процедуре ПриСозданииНаСервере или ПриОткрытии формы.

    Пример псевдокода для формы:

    
    // В процедуре ПриСозданииНаСервере или ПриОткрытии
    Если Объект.ВидОперации = Перечисления.ВидыОперацийРКО.ВыдачаВДругуюКассу Тогда
        Элементы.ПолеПодразделение.Видимость = Истина;
    Иначе
        Элементы.ПолеПодразделение.Видимость = Ложь;
    КонецЕсли;
    
    // Также можно добавить обработчик для поля ВидОперации
    // Процедура ВидОперацииПриИзменении(Элемент)
    //     Если Элемент.Значение = Перечисления.ВидыОперацийРКО.ВыдачаВДругуюКассу Тогда
    //         Элементы.ПолеПодразделение.Видимость = Истина;
    //     Иначе
    //         Элементы.ПолеПодразделение.Видимость = Ложь;
    //     КонецЕсли;
    // КонецПроцедуры
    
  3. Обеспечение корректного заполнения поля:

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

    Рассмотрим процедуру ПриСозданииНаСервере формы. Здесь мы можем установить значение поля при создании нового документа. Также нам потребуется обработчик события ПриИзменении для поля "Касса получатель", чтобы обновлять подразделение, если касса меняется.

    Пример псевдокода для заполнения:

    
    // В процедуре ПриСозданииНаСервере или ПриОткрытии
    Если Объект.ВидОперации = Перечисления.ВидыОперацийРКО.ВыдачаВДругуюКассу Тогда
        Если НЕ ЗначениеЗаполнено(Объект.Подразделение) И ЗначениеЗаполнено(Объект.КассаПолучатель) Тогда
            Объект.Подразделение = Объект.КассаПолучатель.Подразделение; // Присваиваем подразделение из кассы
        КонецЕсли;
    КонецЕсли;
    
    // В обработчике события ПриИзменении для поля "КассаПолучатель"
    // Процедура КассаПолучательПриИзменении(Элемент)
    //     Если Объект.ВидОперации = Перечисления.ВидыОперацийРКО.ВыдачаВДругуюКассу Тогда
    //         Если ЗначениеЗаполнено(Объект.КассаПолучатель) Тогда
    //             Объект.Подразделение = Объект.КассаПолучатель.Подразделение;
    //         Иначе
    //             Объект.Подразделение = Неопределено;
    //         КонецЕсли;
    //     КонецЕсли;
    // КонецПроцедуры
    
  4. Корректная запись в регистры при проведении:

    Самый критичный шаг – это обеспечение записи значения поля Подразделение в регистр ДенежныеСредстваНаличные и любые другие регистры, использующие это измерение, в процедуре проведения документа. Поскольку типовой РКО не заполняет это измерение для операции "Выдача в другую кассу", нам необходимо "подменить" или "дополнить" логику проведения.

    В расширении мы можем заимствовать обработчик проведения документа Документ.РасходныйКассовыйОрдер.ОбработкаПроведения (или создать свой обработчик события "Перед записью" или "При проведении"). В этом обработчике мы должны убедиться, что для движений по регистру ДенежныеСредстваНаличные, создаваемых этим РКО, корректно указывается значение поля Подразделение, взятое из нашего поля на форме.

    Пример псевдокода для обработчика проведения (с учетом типовых движений):

    
    // В процедуре ОбработкаПроведения (в расширении)
    // ...
    // Если процедура ОбработкаПроведения уже существует в расширении и перехватывает типовую,
    // нам нужно найти место, где формируются движения по регистру ДенежныеСредстваНаличные.
    // Обычно это выглядит так:
    
    Движение = Движения.ДенежныеСредстваНаличные.Добавить();
    Движение.ВидДвижения = ВидДвиженияНакопления.Расход;
    Движение.Период = Дата;
    Движение.Сумма = Сумма;
    Движение.Касса = КассаПолучатель; // Или Касса, в зависимости от движения
    // ... другие измерения
    
    // Самое главное: явное указание подразделения
    Движение.Подразделение = Объект.Подразделение;
    // ...
    

    Обратите внимание, что нам, возможно, придется глубоко анализировать типовой код проведения РКО, чтобы точно определить место для вставки нашей логики без нарушения целостности стандартных механизмов.

  5. Проверка и тестирование:

    После реализации расширения обязательно проведите всестороннее тестирование. Создайте РКО с операцией "Выдача в другую кассу", укажите кассу, проверьте автоматическое заполнение подразделения, а затем проведите документ. Убедитесь, что ошибки РЛС больше не возникают, и что данные корректно записываются в регистры. Также проверьте, что для других операций в РКО поле "Подразделение" по-прежнему ведет себя как типовое.

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

2. Пересмотр настроек РЛС

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

  1. Анализ рисков: Прежде чем идти по этому пути, тщательно проанализируйте все риски. Снятие ограничений по подразделениям может нарушить политику безопасности данных и контроля, предоставляя пользователям доступ к информации или операциям, на которые они не должны иметь права.
  2. Изменение профилей групп доступа: Мы можем создать отдельный профиль группы доступа или изменить существующий, чтобы операции с РКО не ограничивались строго по подразделениям. Например, можно исключить проверку по подразделениям для определенного типа документов или операций.

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

3. Проверка используемых видов операций

Хотя в данном случае проблема четко определена для операции "Выдача в другую кассу", всегда полезно убедиться, что для перемещения денежных средств между кассами вы используете именно этот механизм. В 1С:УТ 11.5 предусмотрен двухэтапный механизм для таких операций:

  1. РКО с видом операции "Выдача в другую кассу".
  2. ПКО с видом операции "Поступление из другой кассы".

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

Заключение

Исчезновение поля "Подразделение" из формы Расходного кассового ордера для операции "Выдача в другую кассу" в 1С:Управление торговлей 11.5 после обновлений является характерным примером, когда оптимизация типового функционала вступает в противоречие с конкретными бизнес-процессами и настройками РЛС в организации. Выяснив, что это изменение, скорее всего, является осознанным решением разработчиков для упрощения, мы также обнаружили, что оно создает серьезные проблемы с контролем доступа и аналитикой из-за несогласованности в заполнении регистров.

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

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

← На главную