Как организовать совместную работу нескольких пользователей с одним документом или проектом в 1С?

← На главную

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

Ограничения платформы 1С при параллельной работе с объектом

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

Пессимистическая блокировка формы: когда пользователь открывает форму объекта и начинает его интерактивное редактирование, платформа блокирует объект с помощью механизма пессимистической блокировки (вызовы ЗаблокироватьДанныеДляРедактирования). Другой пользователь при попытке открыть или отредактировать этот же документ получит предупреждение о том, что объект уже заблокирован.
Оптимистическая блокировка и контроль версий: при программной или интерактивной записи объекта платформа проверяет соответствие системного реквизита ВерсияДанных. Если первый пользователь записал свои изменения, а второй в это время держал открытой старую копию данных, при попытке сохранения вторым пользователем возникнет исключение: «Данные были изменены или удалены другим пользователем».

Таким образом, прямое одновременное редактирование одного объекта разными пользователями технически невозможно без конфликтов блокировок. Рассмотрим основные подходы к правильной организации такого бизнес-процесса.

Вариант 1. Статусная модель и последовательная обработка в едином документе

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

Разберем реализацию этого подхода по шагам:

В документе создаем реквизиты для фиксации состояния: Статус (ссылка на перечисление или справочник этапов) и ТекущийИсполнитель (ссылка на справочник Пользователи).
В форме документа в процедуре ПриЧтенииСозданииНаСервере управляем доступностью реквизитов и элементов формы в зависимости от текущего статуса и текущего пользователя сеанса:


&НаСервере
Процедура ПриЧтенииСозданииНаСервере()
    
    ТекущийПользователь = ПараметрыСеанса.ТекущийПользователь;
    ЭтоТекущийИсполнитель = (Объект.ТекущийИсполнитель = ТекущийПользователь);
    
    // Блокируем или открываем доступ к группам реквизитов
    Элементы.ГруппаТехническиеДанные.Доступность = 
        (Объект.Статус = Перечисления.СтатусыПроекта.ТехническаяЭкспертиза) И ЭтоТекущийИсполнитель;
        
    Элементы.ГруппаИсполнение.Доступность = 
        (Объект.Статус = Перечисления.СтатусыПроекта.ВРаботе) И ЭтоТекущийИсполнитель;
        
КонецПроцедуры

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

Вариант 2. Механизм «Бизнес-процессы» и «Задачи»

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

Разберем логику работы механизма:

Создается объект метаданных БизнесПроцесс (например, СогласованиеПроекта), в карте маршрута которого описываются все шаги: создание, техническое согласование, назначение исполнителя, выполнение.
К бизнес-процессу подключается объект Задача (например, ЗадачаИсполнителя). При переходе на точку маршрута платформа автоматически генерирует задачи для конкретных пользователей или ролей.
Каждый пользователь работает со своим персональным списком задач («Мои задачи»). Открывая задачу, исполнитель вносит необходимые данные (либо в саму задачу, либо в связанный документ-предмет) и нажимает кнопку «Выполнено». Бизнес-процесс автоматически направляет работу следующему участнику.

Вариант 3. Хранение независимых данных в регистрах сведений

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

Основной документ или справочник выступает только в роли паспорта проекта или сквозного идентификатора и после первичного создания не перезаписывается.
Для каждого блока данных создается отдельный Регистр сведений (например, ТехническиеПараметрыПроектов, ПлановыеПоказателиПроектов). Измерением регистра выступает ссылка на проект, а ресурсами — конкретные показатели.
Пользователи работают через специализированные рабочие места (обработки) или формы, которые записывают данные напрямую в регистры сведений по своему набору записей:


&НаСервере
Процедура ЗаписатьДанныеЭтапаНаСервере(СсылкаНаПроект, ЗначениеПараметра)
    
    НаборЗаписей = РегистрыСведений.ТехническиеПараметрыПроектов.СоздатьНаборЗаписей();
    НаборЗаписей.Отбор.Проект.Установить(СсылкаНаПроект);
    
    НоваяЗапись = НаборЗаписей.Добавить();
    НоваяЗапись.Проект = СсылкаНаПроект;
    НоваяЗапись.Параметр = ЗначениеПараметра;
    НоваяЗапись.АвторИзменения = ПараметрыСеанса.ТекущийПользователь;
    
    // Запись набора не блокирует сам документ проекта и другие регистры
    НаборЗаписей.Записать();
    
КонецПроцедуры

Такой подход полностью исключает возникновение ошибок блокировки версий объекта (ВерсияДанных), так как разные пользователи пишут данные в независимые таблицы базы данных.

Вариант 4. Архитектура с первичными и сводными документами

Если каждый этап работы представляет собой законченную хозяйственную операцию, методологически верно создавать цепочку подчиненных документов:

Первый пользователь создает документ-основание (например, ЗаявкаНаПроект).
Последующие участники цепочки вводят на основании свои отдельные документы (ТехническоеЗадание, НарядНаВыполнениеРабот, АктПриемки).
Итоговая отчетность или сводный документ собирает данные по цепочке документов или движениям соответствующих регистров.

Для простых цепочек из 3–4 последовательных шагов оптимальным решением будет статусная модель в одном документе. Для сложных и ветвящихся процессов следует использовать бизнес-процессы или независимые регистры сведений.