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