После обновления конфигурации «1С:Управление торговлей» с версии 11.4.8 на 11.4.9 (и выше, включая ветку 11.4.10) многие пользователи столкнулись с неожиданным поведением системы: документ Коммерческое предложение клиенту стал требовать обязательного заполнения поля Контрагент. Это вызывает массу сложностей, так как на этапе подготовки предложения юридическое лицо клиента (Контрагент) часто еще не известно, а работа ведется только с управленческой сущностью — Партнером.
В этой статье мы подробно разберем, почему методология 1С изменилась, как это связано с сервисом 1С:Бизнес-сеть и какими способами можно вернуть привычный функционал, не нарушая логику работы программы.
Рассмотрим архитектурные изменения, которые внедрили разработчики 1С. Начиная с релиза 11.4.9.70, компания официально прекратила поддержку старых протоколов обмена электронными документами через FTP и электронную почту. Им на смену пришел универсальный сервис 1С:Бизнес-сеть.
Для того чтобы документы могли беспрепятственно передаваться между участниками сети, системе необходим четкий идентификатор отправителя и получателя. В среде 1С таким идентификатором выступает связка ИНН/КПП, которая хранится в справочнике Контрагенты. Поскольку Партнер является лишь управленческой категорией и может не иметь юридических данных, методисты 1С приняли решение сделать поле Контрагент обязательным для всех КП, чтобы унифицировать их для работы в цифровой среде.
Важный нюанс: даже если вы не используете и не планируете использовать «1С:Бизнес-сеть», проверка в коде конфигурации все равно срабатывает, блокируя запись документа без указания юридического лица.
Проблема затрагивает не только новые документы, но и исторические данные. После обновления «старые» коммерческие предложения, в которых был указан только партнер, переходят в состояние «ошибки заполнения». При попытке любого изменения или перепроведения такого документа система выдает отказ. Это происходит потому, что в объекте срабатывает стандартное событие ОбработкаПроверкиЗаполнения.
Если вы не хотите вмешиваться в программный код конфигурации, можно пойти по пути наименьшего сопротивления, который часто предлагают консультанты. Разберем его по шагам:
Контрагенты одного общего «технического» контрагента, например, с наименованием «Потенциальный клиент (для КП)».Коммерческое предложение клиенту, добавим фильтр по пустому полю Контрагент и массово проставим созданного технического клиента.Минус этого способа: ваша аналитическая база будет «засорена» лишними записями, и в будущем придется вручную менять технического контрагента на реального при конвертации КП в Заказ клиента.
Для программистов и системных администраторов наиболее правильным решением будет создание небольшого расширения. Это позволит сохранить возможность записи КП только по партнеру, как это было в прошлых версиях. Рассмотрим подробнее, как это реализовать.
Нам необходимо переопределить поведение формы документа и самого объекта. Во-первых, нужно снять признак «Выдавать ошибку» у реквизита на уровне формы. Во-вторых, нужно вмешаться в процедуру проверки заполнения на сервере.
Пример кода для модуля расширения формы документа ФормаДокумента:
&НаСервере
Процедура ПриСозданииНаСервереПосле(Отказ, СтандартнаяОбработка)
// Убираем визуальную проверку (красное подчеркивание) на форме
Элементы.Контрагент.АвтоОтметкаНезаполненного = Ложь;
Элементы.Контрагент.ПроверкаЗаполнения = ПроверкаЗаполнения.НеПроверять;
КонецПроцедуры
Однако простого изменения формы недостаточно, так как проверка может быть жестко прописана в модуле объекта документа. Проанализируем событие ОбработкаПроверкиЗаполнения в модуле объекта Документ.КоммерческоеПредложениеКлиенту. Нам нужно исключить Контрагент из списка проверяемых реквизитов.
Пример реализации в расширении (Модуль объекта):
&Вместо("ОбработкаПроверкиЗаполнения")
Процедура Расш_ОбработкаПроверкиЗаполнения(Отказ, ПроверяемыеРеквизиты)
// Вызываем стандартную проверку, если это необходимо
ПродолжитьВызов(Отказ, ПроверяемыеРеквизиты);
// Находим в массиве проверяемых реквизитов наш Контрагент и удаляем его
ПорядковыйНомер = ПроверяемыеРеквизиты.Найти("Контрагент");
Если ПорядковыйНомер <> Неопределено Тогда
ПроверяемыеРеквизиты.Удалить(ПорядковыйНомер);
КонецЕсли;
КонецПроцедуры
Использование метода &Вместо позволяет полностью контролировать список реквизитов. Если вы хотите действовать более мягко, можно использовать &После, но тогда придется программно очищать состояние Отказ, если ошибка была вызвана именно отсутствием контрагента.
Разберем еще один способ, который не требует написания кода. В расширении конфигурации можно просто изменить свойства заимствованного реквизита:
КоммерческоеПредложениеКлиенту в расширение.Контрагент.Не проверять.Важно: этот способ работает только в том случае, если проверка не прописана «жестко» в коде модуля через функцию ОбщегоНазначения.СообщитьОшибкуЗаполнения. В релизах 11.4.9.x разработчики часто комбинируют свойства метаданных и программные проверки, поэтому метод с кодом (Вариант 2) является более надежным.
Мы выяснили, что принудительное заполнение контрагента — это не ошибка, а осознанная стратегия 1С по продвижению электронного документооборота через «Бизнес-сеть». Однако для многих торговых компаний это ограничение является избыточным.
Для восстановления работоспособности системы мы рекомендуем:
Контрагент.Помните, что при обновлении на более свежие релизы (например, на ветку 11.5 или 12) логика интеграции с сервисами может стать еще плотнее, поэтому использование расширений — это наиболее гибкий способ адаптации системы под ваши нужды.