При переходе на современные версии конфигураций, таких как 1С:Управление торговлей 11.4, 1С:Комплексная автоматизация 2 или 1С:ERP, многие пользователи и разработчики сталкиваются с неожиданным поведением системы: даже если в настройках включено использование договоров, документ РеализацияТоваровУслуг прекрасно проводится с пустым полем Договор. Рассмотрим, почему это происходит, как работает внутренняя логика программы и какими способами можно добиться обязательного заполнения этого реквизита.
Для начала проанализируем ситуацию с точки зрения кода. В типовых решениях на базе УТ 11 проверка заполнения реквизитов часто управляется динамически. Рассмотрим фрагмент кода, который отвечает за исключение договора из списка обязательных проверок:
Если НЕ ЗначениеЗаполнено(Соглашение)
ИЛИ НЕ ОбщегоНазначенияУТ.ЗначениеРеквизитаОбъектаТипаБулево(Соглашение, "ИспользуютсяДоговорыКонтрагентов") Тогда
МассивНепроверяемыхРеквизитов.Добавить("Договор");
КонецЕсли;
Разберем это условие по шагам. Здесь используется оператор ИЛИ, который в языке 1С:Предприятие работает по принципу сокращенных вычислений. Если первое условие НЕ ЗначениеЗаполнено(Соглашение) истинно (то есть соглашение в документе не выбрано), то система сразу переходит к выполнению кода внутри блока Если, не проверяя вторую часть условия. В результате Договор добавляется в МассивНепроверяемыхРеквизитов, и стандартная проверка заполнения его игнорирует.
Выясним причину такого поведения. Если в базе отключено использование соглашений в меню НСИ и администрирование, поле Соглашение в документах остается пустым. В этом случае система считает, что расчеты ведутся в упрощенном режиме, где договор не является ключевым аналитическим разрезом, и отключает строгую проверку.
Проанализируем архитектуру взаиморасчетов в современных конфигурациях. В отличие от старых версий (например, УТ 10.3), где договор был основным и единственным юридическим основанием, в УТ 11 выстроена иерархия объектов. Первичным звеном здесь выступает Соглашение.
Именно в соглашении (типовом или индивидуальном) определяются правила игры:
Когда мы отключаем соглашения в настройках программы, система не перестает опираться на эту логику. Она начинает использовать неявное «виртуальное» соглашение, в котором по умолчанию не задано требование обязательности договора. Таким образом, Договор в УТ 11 воспринимается не как обязательный юридический атрибут, а как дополнительная аналитика учета денежных средств.
Посмотрим на ситуацию со стороны администратора. Включение функциональной опции «Договоры с контрагентами» в разделе настроек лишь разрешает использование этого справочника. Это дает пользователю возможность выбрать договор в документе, но не накладывает на него обязательство делать это в каждом случае. Система исходит из того, что по одним сделкам вы можете работать по договору, а по другим — просто по счетам или заказам.
Расчеты в системе в любом случае будут зафиксированы. Если договор не заполнен, объектом расчетов станет сам документ (заказ или накладная). Для управленческого учета в УТ 11 этого достаточно, но это создает серьезные проблемы при интеграции с другими системами.
Рассмотрим подробнее, к чему приводит отсутствие договора в реализации при обмене данными с 1С:Бухгалтерия предприятия 3.0. В бухгалтерском учете на счетах 60 и 62 договор является обязательным субконто. Провести документ без него невозможно.
При синхронизации возникают следующие сценарии:
Поэтому требование бухгалтеров сделать поле Договор обязательным в УТ 11 является абсолютно обоснованным для обеспечения чистоты учета.
Разберем по шагам, как можно решить задачу, не прибегая к изменению программного кода:
1. Использование типовых соглашений. Даже если бизнес-процесс компании не предполагает использование индивидуальных соглашений с каждым клиентом, рекомендуется включить функциональную опцию «Соглашения с клиентами». Вы можете создать одно Типовое соглашение для всех клиентов. В нем на закладке «Условия оплаты» нужно установить настройку «Требуется указание договора, расчеты ведутся по договорам». В этом случае, как только соглашение будет подставлено в документ (автоматически или вручную), поле Договор станет обязательным для заполнения.
2. Настройка детализации расчетов. Если в договоре или соглашении установлена детализация «По договорам», система будет более жестко отслеживать заполнение этого поля, так как без него она не сможет корректно распределить движения в регистре РасчетыСКлиентами.
Если штатные методы с соглашениями кажутся слишком громоздкими, проанализируем вариант с программной доработкой. Чтобы не снимать конфигурацию с поддержки, лучше всего использовать механизм Расширений.
Мы можем перехватить процедуру ПередЗаписью или использовать обработку заполнения. Рассмотрим пример логики, которую можно внедрить через расширение для проверки наличия договора:
&После("ПередЗаписью")
Процедура ПроверкаДоговора_ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
Если РежимПроведения = РежимПроведенияДанных.Проведение Тогда
Если НЕ ЗначениеЗаполнено(ЭтотОбъект.Договор) Тогда
ТекстСообщения = "Поле 'Договор' не заполнено! Проведение документа невозможно.";
ОбщегоНазначенияКлиентСервер.СообщитьПользователю(ТекстСообщения, ЭтотОбъект, "Договор");
Отказ = Истина;
КонецЕсли;
КонецЕсли;
КонецПроцедуры
Этот код принудительно прервет проведение документа, если реквизит Договор пуст, независимо от того, что прописано в соглашениях или системных функциях типового решения. Это самый надежный способ «успокоить» бухгалтерию и гарантировать порядок в аналитике.
Подводя итог нашему анализу, отметим, что поведение УТ 11.4 в отношении договоров — это не ошибка, а особенность гибкой архитектуры. Система предоставляет возможность вести учет без лишней бюрократии там, где это допустимо. Однако для корректного взаимодействия с бухгалтерией и ведения четких взаиморасчетов, необходимо либо грамотно настроить Соглашения, либо внедрить дополнительный контроль через Расширения.
Рассмотренные нами методы позволяют выбрать оптимальный путь: от чисто административных настроек до точечных программных правок. Выяснив причину и логику работы системы, вы сможете эффективно управлять учетом и избегать ошибок при обмене данными.