Проблема одновременного редактирования одного и того же объекта (документа или справочника) в среде 1С является классической дилеммой. Платформа спроектирована таким образом, чтобы защищать целостность данных с помощью объектных блокировок. Когда один пользователь начинает редактировать форму, система «захватывает» объект, и второй пользователь при попытке записи получает известную ошибку: «Данные объекта изменены или удалены другим пользователем». Однако в условиях интенсивной работы, например, на больших складах или в отделах продаж, возникает необходимость совместного наполнения одного документа. Разберем подробно, как можно обойти это ограничение, используя различные технические подходы.
Прежде чем переходить к решениям, проанализируем ситуацию. В 1С блокировка устанавливается на весь объект целиком. Это означает, что даже если один пользователь редактирует «Комментарий», а второй добавляет строку в «Табличную часть», платформа не сможет автоматически объединить эти изменения. Система сравнивает ВерсияДанных объекта в базе и в памяти. Если они не совпадают — запись отклоняется. Рассмотрим по шагам, как можно реализовать многопользовательский ввод данных.
Наиболее простой, но эффективный метод — предотвратить конфликт на этапе открытия формы. Если объект уже занят одним сотрудником, второму пользователю форма должна открываться строго в режиме «Только просмотр». Для этого проанализируем использование метода ЗаблокироватьДанныеДляРедактирования().
В модуле формы, в обработчике ПриЧтенииНаСервере или ПриОткрытии, мы можем проверить наличие блокировки. Если объект заблокирован, мы выводим предупреждение и программно устанавливаем свойство ТолькоПросмотр = Истина.
// Пример проверки блокировки при открытии формы
&НаСервере
Процедура ПриЧтенииНаСервере(ТекущийОбъект)
Попытка
ТекущийОбъект.Заблокировать();
Исключение
ЭтаФорма.ТолькоПросмотр = Истина;
ОбщегоНазначенияКлиентСервер.СообщитьПользователю("Документ редактируется другим пользователем. Доступен только просмотр.");
КонецПопытки;
КонецПроцедуры
Если бизнес-процесс требует именно одновременного ввода строк (например, несколько операторов вносят позиции в один огромный заказ), мы должны отказаться от хранения данных непосредственно в табличной части документа. Вместо этого проанализируем архитектуру с использованием Регистров сведений.
Создадим независимый регистр сведений, где одним из измерений будет Ссылка на наш документ. При добавлении строки пользователем данные записываются не в объект документа, а сразу в этот регистр. Поскольку записи в регистре независимы, несколько пользователей могут одновременно создавать записи, относящиеся к одному документу, не блокируя сам заголовок (объект) документа.
На форме документа вместо стандартной табличной части разместим ДинамическийСписок, настроенный на этот регистр сведений. Это позволит пользователям видеть изменения друг друга практически в реальном времени, если настроить период автообновления списка.
В современных версиях платформы 8.3 реализован механизм Системы взаимодействия. Мы можем использовать его для оповещения всех открытых форм документа об изменениях. Рассмотрим алгоритм работы:
Ссылка документа.ОбновитьОтображениеДанных()).Этот подход создает иллюзию «живого» документа, как в Google Docs, где изменения появляются мгновенно.
Рассмотрим более сложный, «продвинутый» метод — программное слияние (Merge) изменений. В этом случае мы позволяем всем пользователям открывать форму на редактирование без жестких блокировок. Однако в момент нажатия кнопки «Записать» мы выполняем следующий алгоритм:
Для реализации этого метода потребуется написать процедуру сравнения коллекций ТабличнаяЧасть. Это трудоемко, но позволяет сохранить привычный интерфейс документа.
Выясним причину, по которой пользователи хотят редактировать именно документ. Часто это просто привычка. Профессиональное решение задачи — разработка специальной обработки (АРМ), которая визуально напоминает документ, но работает с данными иначе. В АРМ можно реализовать построчную запись в базу данных (через фоновые задания или небольшие транзакции), что полностью снимает проблему блокировки всего документа. Как было отмечено в обсуждении, это может выглядеть как «изврат», но для высоконагруженных систем это стандарт индустрии.
Проанализируем ситуацию: возможно, один огромный документ — это архитектурная ошибка. Если над заказом работают разные отделы (склад, логистика, финансы), целесообразно разделить его на несколько связанных документов. Каждый отдел будет работать со своим объектом, а общие данные будут агрегироваться в «головном» документе через механизмы проведения или отчетности. Это исключит пересечение прав доступа и блокировок.
Выбор метода зависит от квалификации разработчика и критичности требований пользователей. Если нужно «быстро и просто» — используйте Решение 1 (открытие на чтение). Если требуется полноценная совместная работа — рекомендуем Решение 2 (перенос данных в регистры) в сочетании с Решением 3 (система взаимодействия). Помните, что попытка обмануть механизмы блокировок 1С «в лоб» может привести к потере данных, поэтому всегда обеспечивайте строгий контроль версий при программной записи.