Как настроить значения по умолчанию для пользователей в 1С:Управление торговлей 11?

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

При переходе на современные редакции «1С:Управление торговлей» (УТ 11) с устаревших конфигураций «1С:Торговля и склад 7.7» или «Управление торговлей 10.3» многие специалисты сталкиваются с неожиданным изменением: в системе отсутствует привычный справочник или регистр персональных настроек пользователя, где ранее можно было жестко задать реквизиты вроде «Основной склад», «Основной покупатель» или «Основная касса». Разберем, как устроен этот механизм в УТ 11, почему разработчики изменили архитектуру и как настроить автозаполнение реквизитов штатными средствами и с помощью доработок.

Архитектурные особенности УТ 11: почему нет единых настроек пользователя

Проанализируем концепцию типовой конфигурации. В УТ 11 разработчики отказались от концепции жестко зафиксированных персональных значений по умолчанию для каждого оператора. Вместо этого задействованы другие принципы:

  1. Статистический анализ частоты выбора: система отслеживает действия пользователя. Если реквизит (например, склад или организация) систематически выбирается в документах одного вида (по алгоритму анализа истории последних созданных документов), система начинает подставлять его автоматически на основе регулярности и актуальности выбора.
  2. Использование соглашений с клиентами: в УТ 11 ключевые торговые параметры (склад отгрузки, организация, валюта, график расчетов) привязаны к коммерческим условиям, зафиксированным в типовых или индивидуальных соглашениях, а не к карточке оператора.
  3. Привязка оборудования к рабочему месту: кассы ККМ, сканеры штрихкодов и фискальные накопители связываются со справочником рабочих мест текущего компьютера или сеанса, что исключает путаницу при работе разных сотрудников за одним терминалом.
  4. Подстановка из подразделения: для пользователя можно явно определить реквизит Подразделение в справочнике Пользователи, откуда подтягиваются связанные параметры.

Вариант 1. Использование штатных механизмов без изменения конфигурации

Прежде чем переходить к доработке программного кода, рассмотрим возможности программы, доступные в пользовательском режиме:

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

Вариант 2. Программная установка значений в обработчиках формы документа

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


#Область ОбработчикиСобытийФормы

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

#КонецОбласти

Также на стороне формы можно обработать сопутствующие события изменения партнера для корректного пересчета связанных реквизитов документа:


Если Объект.Партнер.Пустая() Тогда
    Объект.Партнер = ПолучитьРозничногоПокупателяНаСервере();
    ПартнерПриИзменении(Объект.Партнер);
КонецЕсли;

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

Вариант 3. Реализация через расширение в модуле объекта («ОбработкаЗаполнения»)

Разберем наиболее надежный и архитектурно правильный метод доработки с сохранением конфигурации на поддержке. Для этого используем расширение конфигурации и перехватим событие заполнения данных объекта:

  1. Подключим расширение конфигурации без снятия основной конфигурации с поддержки.
  2. Добавим в расширение требуемый документ (например, РеализацияТоваровУслуг или ЗаказКлиента).
  3. В модуле объекта документа добавим обработчик с директивой &После("ОбработкаЗаполнения").

Рассмотрим пример кода в модуле объекта расширения:


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

Такой подход обеспечивает выполнение логики на стороне сервера, не создает лишних клиент-серверных вызовов при открытии формы и гарантирует, что реквизиты будут заполнены как при ручном создании документа, так и при программной генерации.

← На главную