Как правильно обрабатывать дублирующиеся реквизиты ФизЛицо и ФизическоеЛицо в 1С:Розница?

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

Выясним причину появления двух похожих реквизитов

Для начала проанализируем ситуацию с точки зрения архитектуры системы. Наличие двух реквизитов — это не ошибка конкретной базы, а результат эволюции программы. Рассмотрим основные причины:

1. Влияние БСП: Реквизит ФизическоеЛицо является стандартным для «Библиотеки стандартных подсистем» (БСП). Он используется для общих механизмов (права доступа, личные кабинеты, синхронизация).
2. Наследие «Розницы»: Реквизит ФизЛицо — это «родной» реквизит конфигурации «Розница», который появился задолго до глубокой интеграции с БСП. Он зашит во многие старые механизмы, включая работу с торговым оборудованием и печатные формы ККТ.
3. Обратная совместимость: Фирма «1С» сохраняет оба реквизита, чтобы не нарушить работу существующих доработок у пользователей, которые обновляются с очень старых версий.

Проанализируем риски использования только одного реквизита

Если ваш алгоритм привязан только к ФизЛицо, а заполнено только ФизическоеЛицо, вы можете столкнуться с тем, что в чеках ККТ вместо ФИО кассира будет выводиться «Администратор» или поле останется пустым. Это критично для соблюдения кассовой дисциплины (ФФД 1.05 и выше), где передача ИНН и ФИО кассира обязательна.

Разберем, как проверить, какой реквизит используется в вашем конкретном случае. Проведем простой эксперимент: попробуем изменить значение в одном поле и пробить тестовый чек. Если в чеке отобразилось значение из ФизЛицо, значит, кассовый модуль вашей версии «Розницы» обращается именно к нему.

Вариант решения 1: Программная обработка исключений

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

Если ЗначениеЗаполнено(Объект.ФизЛицо) Тогда
    ВыбранноеФизЛицо = Объект.ФизЛицо;
ИначеЕсли ЗначениеЗаполнено(Объект.ФизическоеЛицо) Тогда
    ВыбранноеФизЛицо = Объект.ФизическоеЛицо;
Иначе
    // Если оба пусты, пытаемся получить данные из связанного сотрудника или ответственного
    ВыбранноеФизЛицо = Справочники.ФизическиеЛица.ПустаяСсылка();
КонецЕсли;

Этот подход позволяет алгоритму работать корректно, даже если данные в базе заполнены не полностью. Однако он не решает проблему «грязных данных».

Вариант решения 2: Массовое заполнение реквизитов

С точки зрения архитектуры данных, ситуация, когда два реквизита дублируют друг друга, нарушает третью нормальную форму (3NF). Чтобы привести базу в порядок, мы рекомендуем выполнить разовую обработку по заполнению пустых значений. Проанализируем логику такой обработки:

1. Выбираем всех пользователей из справочника Пользователи.
2. Проверяем: если ФизЛицо пустое, а ФизическоеЛицо заполнено — копируем значение.
3. Проверяем обратную ситуацию: если ФизическоеЛицо пустое — заполняем его данными из ФизЛицо.
4. Записываем объект, предварительно отключив проверки (если это необходимо для ускорения).

Рассмотрим пример кода для такой обработки:

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

Вариант решения 3: Автоматическая синхронизация при записи

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

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

Важные замечания по кассовой технике

Посмотрим на ситуацию с технической стороны взаимодействия с ККТ. В современных реалиях важно не просто наличие ссылки на ФизическоеЛицо, но и наличие заполненного ИНН в карточке этого физлица. Если вы синхронизируете реквизиты, обязательно убедитесь, что в справочнике ФизическиеЛица у соответствующих записей корректно указаны ИНН и полные ФИО.

Резюмируем: наиболее правильным подходом будет сочетание второго и третьего вариантов. Сначала мы наводим порядок в текущей базе с помощью обработки, а затем внедряем механизм синхронизации (или административный регламент заполнения), чтобы данные всегда были идентичны. Это гарантирует стабильную работу как старых механизмов «Розницы», так и новых подсистем БСП.