Почему не выполняется условие при проверке вида счета-фактуры в 1С и как правильно сравнивать значения перечислений

Программист 1С v8.3 (Обычные формы) 1C:Бухгалтерия Бухгалтерский учет IT и автоматизация бизнеса
← На главную

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

Причина ошибки: сравнение ссылки со строкой

Проанализируем природу реквизитов типа ПеречислениеСсылка. В прикладных конфигурациях 1С (включая 1С:Бухгалтерию) реквизиты, отвечающие за вид документа (например, вид счета-фактуры), хранят не строковый текст, а строго типизированную ссылку на элемент метаданных перечисления.

Когда мы пишем условие, сравнивающее переменную ссылочного типа с текстовой строкой, платформа выполняет строгое сравнение типов. Поскольку тип ПеречислениеСсылка.ВидСчетФактурыВыставленного не равен типу Строка, логическое выражение всегда возвращает значение Ложь.

Как правильно обращаться к значениям перечислений в коде

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

Посмотрим на пример правильного оформления условия:


Если ВидСчетФактуры = Перечисления.ВидСчетФактурыВыставленного.НаАванс Тогда
    ПредставлениеНомера = "А" + ПредставлениеНомера;
КонецЕсли;

В данном случае платформа сравнивает две ссылки одного типа, и при совпадении условий ветка кода успешно выполняется.

Сравнение значений перечислений в запросах

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

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


ВЫБРАТЬ
    СчетФактура.Ссылка КАК Ссылка,
    СчетФактура.Номер КАК Номер,
    СчетФактура.ВидСчетФактуры КАК ВидСчетФактуры
ИЗ
    Документ.СчетФактураВыставленный КАК СчетФактура
ГДЕ
    СчетФактура.ВидСчетФактуры = ЗНАЧЕНИЕ(Перечисление.ВидСчетФактурыВыставленного.НаАванс)

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

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

  1. Зависимость от синонима: функция Строка(Ссылка) возвращает синоним элемента перечисления. Если пользователь или разработчик изменит синоним в конфигураторе, логика программы нарушится без генерации синтаксических ошибок.
  2. Проблемы локализации: при смене языка интерфейса строковое представление изменится, и условие перестанет выполняться.

Если по архитектурным причинам все же требуется получить строковое системное имя элемента (идентификатор), применяют функцию XMLСтрока() или чтение метаданных:


ИмяЗначения = XMLСтрока(ВидСчетФактуры);
// Либо через объектную модель метаданных:
ИмяЭлемента = ВидСчетФактуры.Метаданные().Имя;

Особенности модификации номера для печатной формы

Разберем важные технические и учетные нюансы при добавлении префиксов и буквенных индексов к номерам счетов-фактур:

  1. Порядок очистки номера: в типовых конфигурациях перед выводом на печать вызываются стандартные процедуры удаления лидирующих нулей и префиксов информационных баз. Добавлять буквенный индекс (например, «А») необходимо строго после выполнения процедур типового форматирования номера, иначе системные алгоритмы могут некорректно обрезать добавленный символ.
  2. Риски расхождения с отчетностью: если префикс «А» добавляется исключительно в макет печатной формы, в базе данных номер останется прежним. Это приведет к расхождениям между печатным документом у контрагента и данными книги продаж, а также раздела 9 декларации по НДС, что вызывает требования пояснений со стороны контролирующих органов.
  3. Использование автонумерации: более надежным решением является назначение префикса на уровне самого документа при записи или в процедуре ПриУстановкеНовогоНомера (через подписку на события). В этом случае номер будет единым и в регистрах учета, и во всех отчетах.
  4. Внешние печатные формы (ВПФ): если конфигурация находится на поддержке, правильнее оформить измененную логику вывода счета-фактуры в виде внешней печатной формы без снятия конфигурации с типовой поддержки.
← На главную