При работе в крупных холдингах часто возникает ситуация, когда одна торговая компания (Фирма А) продает товар, который фактически находится на остатках у нескольких других юридических лиц (Фирма Б и Фирма В). В системе «1С:ERP Управление предприятием» настроена схема Интеркампани, позволяющая одной организации продавать товары другой. Однако возникает закономерный вопрос: как система определит, у кого именно «забрать» товар в первую очередь, если он есть у обоих владельцев? Рассмотрим этот механизм подробно и разберем, можно ли им управлять.
Начнем с того, что в типовом решении «1С:ERP» (редакции 2.4 и 2.5) штатный функционал для указания приоритета организаций-владельцев в интерфейсе отсутствует. В справочнике настроек передачи товаров между организациями мы указываем лишь саму возможность передачи, но не можем проставить весовые коэффициенты или порядковые номера.
Проанализируем, как ведет себя система «под капотом». Когда пользователь оформляет продажу или когда регламентное задание формирует документы «Передача товаров», система выполняет запрос к остаткам по регистру ТоварыОрганизаций. В этом запросе участвуют все организации, для которых в регистре сведений НастройкиПередачиТоваровМеждуОрганизациями разрешена передача текущему продавцу.
Выясним причину, по которой выбор кажется случайным. В программном коде 1С, формирующем временные таблицы для Интеркампани, чаще всего отсутствует жесткая инструкция УПОРЯДОЧИТЬ ПО. Это означает, что последовательность строк в результате запроса определяется СУБД (Microsoft SQL Server, PostgreSQL и др.) произвольно. На практике это обычно соответствует одному из двух вариантов:
Рассмотрим подробнее, где именно в коде происходит эта магия. Основная логика распределения остатков между организациями сосредоточена в общем модуле (или менеджере временных таблиц), который подготавливает данные для обеспечения продаж. В частности, стоит обратить внимание на функции, работающие с МенеджерВременныхТаблицИнтеркампани.
Система строит дерево возможных перепродаж. Если у вас цепочка простая (Б -> А и В -> А), то выбор между Б и В будет зависеть от того, какая запись первой попадет в выборку запроса. Если же цепочки разной длины (например, Б -> А, а В -> Г -> А), алгоритм может отдавать предпочтение более коротким путям, чтобы минимизировать количество создаваемых документов «Передача товаров».
Поскольку типовая конфигурация не дает возможности управлять приоритетом, разберем, как реализовать эту задачу с помощью расширения конфигурации. Это наиболее правильный и безопасный путь, не требующий снятия системы с поддержки.
Шаг 1: Добавление реквизита приоритета
Для начала нам нужно место, где пользователь сможет указать порядок. Создадим в расширении дополнительный реквизит для справочника Организации или создадим новый регистр сведений, где будет храниться связь: «Организация-получатель — Организация-владелец — Приоритет (число)».
Шаг 2: Модификация запроса подбора
Нам необходимо найти место в коде, где формируется запрос к остаткам Интеркампани. Обычно это программное формирование текста запроса в модулях, отвечающих за распределение запасов. Разберем пример логики, которую нужно внедрить:
// Пример модификации запроса в расширении
&Вместо("ПодготовитьЗапросПоОстаткамИнтеркампани")
Процедура ИмяПрефикс_ПодготовитьЗапросПоОстаткамИнтеркампани(ТекстЗапроса)
// Добавляем в текст запроса соединение с нашей таблицей приоритетов
ТекстЗапроса = ТекстЗапроса + "
|ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ИмяПрефикс_ПриоритетыИнтеркампани КАК Приоритеты
|ПО ТаблицаОстатков.ОрганизацияВладелец = Приоритеты.ОрганизацияВладелец
| И ТаблицаОстатков.ОрганизацияПолучатель = Приоритеты.ОрганизацияПолучатель
|УПОРЯДОЧИТЬ ПО
| Приоритеты.ЗначениеПриоритета ВОЗР,
| ТаблицаОстатков.ОрганизацияВладелец.Наименование";
КонецПроцедуры
Шаг 3: Тестирование распределения
После внесения изменений проанализируем ситуацию в рабочем месте «Оформление передач и выкупов». Теперь при заполнении документов система будет сначала пытаться «закрыть» отрицательные остатки за счет организации с наивысшим приоритетом (например, значение 1), и только при нехватке товара переходить к организации с приоритетом 2.
Если возможность программирования ограничена, можно рассмотреть организационные методы влияния на подбор:
Подводя итог, можно констатировать: в стандартной «1С:ERP» выбор между несколькими владельцами товара в схеме Интеркампани является технологически детерминированным, но бизнес-ориентированно произвольным. Система выбирает «первого попавшегося» по внутренним критериям базы данных. Для реализации четкой бизнес-логики (например, «сначала продаем остатки собственного производства, потом — закупленные у сторонних поставщиков») требуется небольшая доработка через механизм расширений, которая добавит поле Приоритет в алгоритмы подбора.