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