В практике разработки на платформе 1С часто возникают задачи, требующие не только знания синтаксиса, но и глубокого понимания структуры типовых конфигураций, а также умения применять логические уловки для оптимизации кода. Сегодня мы разберем интересную задачу-головоломку: как составить запрос к базе 1С:Бухгалтерия предприятия 3.0, который выберет строго определенные типы денежных документов (ПКО, РКО, Поступление и Списание по счету), при этом документы должны быть одновременно непроведенными и не помеченными на удаление. Главное ограничение — длина текста запроса не должна превышать 55 символов.
Первым делом проанализируем список необходимых типов документов: ПриходныйКассовыйОрдер, РасходныйКассовыйОрдер, ПоступлениеНаРасчетныйСчет и СписаниеСРасчетногоСчета. Если пытаться обращаться к каждой таблице по отдельности или использовать ОБЪЕДИНИТЬ ВСЕ, мы моментально выйдем за рамки ограничения в 55 символов. Одно только перечисление имен таблиц займет гораздо больше места.
Следовательно, нам необходимо найти единый объект метаданных, который уже объединяет эти документы. В конфигурации 1С:Бухгалтерия предприятия 3.0 таким объектом является журнал документов Деньги. Этот журнал специально предназначен для консолидации информации по кассовым и банковским операциям. Использование журнала вместо нескольких таблиц — это ключевой шаг к сокращению кода.
Стандартное условие для фильтрации документов выглядит следующим образом: ГДЕ Проведен = ЛОЖЬ И ПометкаУдаления = ЛОЖЬ. Однако в языке запросов 1С есть возможность сравнить два булевых поля между собой. Проанализируем таблицу истинности для полей Проведен (Posted) и ПометкаУдаления (DeletionMark):
Поскольку в системе 1С проведенный документ не может быть одновременно помечен на удаление (платформа снимает проведение при установке пометки), вариант "Истина = Истина" фактически исключен. Таким образом, краткое условие ГДЕ Проведен = ПометкаУдаления полностью заменяет громоздкую конструкцию с проверкой каждого поля на ЛОЖЬ.
Язык запросов 1С поддерживает как русский, так и английский синтаксис. Для экстремального сокращения длины (code golfing) мы можем комбинировать ключевые слова или выбирать те, что короче. Например, SELECT длиннее, чем ВЫБРАТЬ, но WHERE длиннее, чем ГДЕ. Также мы можем опустить использование секции ИЗ (FROM), если обращаемся напрямую к полям журнала через точку в секции выбора, хотя это зависит от контекста парсера.
Рассмотрим вариант решения, который укладывается в заданные рамки. Мы будем использовать обращение к журналу документов и наше оптимизированное условие.
Проанализируем структуру финального запроса, который удовлетворяет всем условиям задачи. Запрос использует английские наименования полей метаданных, которые короче русских аналогов (DeletionMark вместо ПометкаУдаления и Posted вместо Проведен).
Вариант запроса длиной 54 символа:
SELECT DocumentJournal.Деньги.* ГДЕ DeletionMark=Posted
Разберем, почему этот код работает:
SELECT — стандартный оператор выбора.DocumentJournal.Деньги.* — мы обращаемся к журналу документов "Деньги" и выбираем все его поля. Это избавляет нас от необходимости прописывать секцию ИЗ (FROM), так как путь к таблице указан непосредственно в поле выбора.ГДЕ — русское ключевое слово (3 символа), которое короче английского WHERE (5 символов).DeletionMark=Posted — то самое логическое сравнение. Мы не используем пробелы вокруг знака равенства, чтобы сэкономить еще 2 символа.Если бы нам требовалось еще больше сократить текст, мы могли бы рассмотреть использование псевдонимов, однако в рамках одного простого запроса к одной таблице это обычно увеличивает длину. Важно помнить, что использование * (звездочки) разрешено в языке запросов 1С только для журналов или при проверке существования записей, и в данном случае это идеально подходит для нашей цели.
Рассмотрим еще один пример, демонстрирующий использование только русского синтаксиса, который часто оказывается короче из-за специфики имен метаданных:
ВЫБРАТЬ ЖурналДокументов.Деньги.* ГДЕ ПометкаУдаления=Проведен
Этот вариант нагляднее, но его длина составляет 59 символов, что не проходит по условию задачи (лимит 55). Это наглядно показывает, почему для решения подобных головоломок профессионалы прибегают к смешиванию языков и использованию англоязычных идентификаторов полей платформы.
Важное замечание: Несмотря на изящность решения DeletionMark=Posted, в реальных рабочих проектах рекомендуется использовать явную проверку на ЛОЖЬ. Это делает код более читаемым для других разработчиков и исключает теоретическую ошибку, если в базу попадут некорректно записанные данные (одновременно проведенные и удаленные объекты), что может случиться при использовании низкоуровневых методов записи объектов с отключенными проверками.