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