Управление товарными потоками: автоматизация дистрибьюции в 1С

7 октября 2026 · infolimp.ru

Проблема: «Слепые зоны» в стандартной логике товародвижения

Когда дистрибьютор переходит от простых B2B-продаж к управлению товарными потоками с элементами вендор-менеджмента, в типовой конфигурации «1С:Управление торговлей» (или УТ 11) возникает три «слепых зоны»:

• Пересортица на стыке «Склад дистрибьютора ↔ Склад сети»: стандартный документ «Перемещение товаров» не предусматривает возврата брака/остатка с наценкой за логистику.
• Фиксация права собственности: по FBO (Free Balance Operation) товар может быть на балансе у вендора, но физически — на складе дистрибьютора. 1С «видит» его как остаток, но не учитывает обязательства по оплате при отгрузке.
• Автоматизация ретро-бонусов в потоке: когда скидка зависит не от объема заказа, а от объема продаж за квартал с учетом возврата брака.

Предупреждение: Попытка закрыть эти «слепые зоны» через «бумажный учет» или через разовые документы «Корректировка записей регистров» (да-да, я знаю, что кто-то так делает) — верный путь к расхождению остатков в конце месяца. Одна ошибка в дате или сумме корректировки — и весь отчет по валовой прибыли «плывет».

Технический разбор: почему «Заказ на перемещение» не спасает

Типовой механизм Документы.ЗаказНаПеремещение создает ожидание поступления. Но при возврате брака в рамках дистрибьюции возникает ситуация: товар A (брак) не равен товару A (годный). Складской учет 1С, построенный на РегистрНакопления.ТоварыНаСкладах, не различает партию по признаку «брак/годный» в рамках одного номенклатурного номера. Решение — использование дополнительных реквизитов серии или создание отдельного вида номенклатуры с префиксом «БРАК_». Однако это ломает стандартную цепочку ценообразования.

Рассмотрим простой пример: попытка корректно распределить транспортные расходы при возврате брака от сети.

// Псевдокод: Распределение услуги "Возврат логистика" на товарный поток
// Предполагаем, что есть документ "ВозвратТоваров" с видом операции "Возврат брака дистрибьютора"
Процедура ОбработкаПроведения(Отказ, Режим)
    
    Если Режим = РежимПроведенияДокумента.Оперативный Тогда

        // Собираем все строки возврата, где номенклатура имеет признак "Требует утилизации через вендора"
        Запрос = Новый Запрос;
        Запрос.Текст = 
        "ВЫБРАТЬ
        |    ВозвратТоваров.Номенклатура,
        |    ВозвратТоваров.Количество,
        |    ВозвратТоваров.Цена
        |ИЗ
        |    Документ.ВозвратТоваров.Состав КАК ВозвратТоваров
        |ГДЕ
        |    ВозвратТоваров.Ссылка = &Ссылка
        |    И ВозвратТоваров.Номенклатура.ПризнакУтилизации = ИСТИНА";
        Запрос.УстановитьПараметр("Ссылка", ЭтотОбъект.Ссылка);
        
        Выборка = Запрос.Выполнить().Выбрать();
        
        Пока Выборка.Следующий() Цикл
            
            // Список значений для поиска услуги логистики
            СписокУслуг = Новый СписокЗначений;
            СписокУслуг.ЗагрузитьЗначения(Номенклатура.УслугиПоВозвратуБрака); // через реальный API ИТС
            
            // Создаем запись в регистре "СтоимостьТоваров" с отрицательной суммой (возврат)
            Движение = РегистрыНакопления.СтоимостьТоваров.СоздатьМенеджерЗаписи();
            Движение.Период = ЭтотОбъект.Дата;
            Движение.Номенклатура = Выборка.Номенклатура;
            Движение.Регистратор = ЭтотОбъект.Ссылка;
            // Сумма услуги логистики, которую мы "повесили" на возврат
            Движение.Сумма = -Выборка.Количество * ЦенаУслугиПоКатегории(Выборка.Номенклатура.Категория); 
            Движение.Записать(Истина);
            
        КонецЦикла;
        
    КонецЕсли;
    
КонецПроцедуры

Ключевой тезис: В дистрибьюции важно не просто отразить факт перемещения товара, а корректно «привязать» к товарному потоку все сопутствующие обязательства (логистика, утилизация, маркетинговые вычеты). Игнорирование этого — прямая дорога к искажению финансового результата.

Сравнительный анализ: Ручной учет vs. Автоматизация с «Задачами дистрибьютора»

Рассмотрим два подхода к управлению товарным потоком «Возврат просрочки от розничной сети». Разница — в способе фиксации стоимости логистической услуги.

Подход 1: «Ручной учет через документ КорректировкаЗаписейРегистров»

Условия применимости: единичные случаи (до 5 возвратов в месяц), когда сумма услуги фиксирована (например, 5000 руб за машину).

• Плюсы: быстрая реализация, не требует доработки метаданных.
• Минусы: невозможно выстроить аналитику по каждому возврату. Нет связи с документом «Возврат товаров» — теряется привязка к конкретной отгрузке.

Подход 2: «Автоматизация с использованием серий и пакетной обработки»

Условия применимости: более 20 возвратов в месяц, работа с крупными сетями (X5, Магнит). Обязательно ведение серийного учета по срокам годности.

// Фрагмент обработки: Создание пакета товаров для возврата с автоматическим расчетом штрафа
// Используется механизм "ПакетЗаданий" (через реальный API ИТС)
Процедура СформироватьПакетВозврата(ДатаНачала, ДатаОкончания)
    
    // Находим все заказы клиентов, по которым прошла отгрузка и срок годности истек менее 30 дней назад
    ТекстЗапроса = "
    |ВЫБРАТЬ
    |    Реализация.Ссылка,
    |    Реализация.Дата,
    |    Реализация.Контрагент,
    |    Реализация.СуммаДокумента
    |ПОМЕСТИТЬ ВТ_РеализацииПериод
    |ИЗ
    |    Документ.РеализацияТоваровУслуг КАК Реализация
    |ГДЕ
    |    Реализация.Дата МЕЖДУ &Нач И &Кон
    |    И Реализация.Проведен = ИСТИНА
    |ИНДЕКСИРОВАТЬ ПО
    |    Контрагент";
    
    // ... продолжение запроса с отбором по сериям с истекшим сроком ... (опущено для краткости)
    
    // Создаем задание для фонового обмена с распределительным центром
    // через HTTP-запрос к сервису "Управление возвратами" (API ИТС)
    Соединение = Новый HTTPСоединение("retail.dist.1c.ru", 443,,,, Новый ЗащищенноеСоединениеOpenSSL);
    Запрос = Новый HTTPЗапрос("/api/v2/create-return?batch=" + ПолучитьИдентификаторПакета());
    Запрос.УстановитьТелоИзСтроки(ПостроитьJSON(ВТ_РеализацииПериод), "UTF-8");
    
    Ответ = Соединение.ВызватьHTTPМетод("POST", Запрос);
    
    Если Ответ.КодСостояния = 200 Тогда
        // Обработка ответа: создание документа "Возврат товаров" с автоматическим заполнением
        Возврат = Документы.ВозвратТоваров.СоздатьДокумент();
        Возврат.Дата = ТекущаяДата();
        Возврат.Контрагент = Выборка.Контрагент; // из пакета
        Возврат.ВидОперации = Перечисления.ВидыОперацийВозвратов.ВозвратБрака;
        Возврат.Записать(РежимЗаписиДокумента.Проведение);
    Иначе
        ЗаписьЖурналаРегистрации("Ошибка", УровеньЖурналаРегистрации.Ошибка, "Пакетный возврат",
            "Ошибка сервера: " + Ответ.КодСостояния);
    КонецЕсли;
    
КонецПроцедуры

Чек-лист: «Переход на автоматизацию товарных потоков»

Если вы решили внедрить полноценное управление дистрибьюцией в 1С (с опорой на dist.1c.ru как источник интеграционных решений), выполните эти шаги в строгой последовательности:

1. Аудит регистров накопления: Убедитесь, что РегистрНакопления.ТоварыНаСкладах и РегистрНакопления.СтоимостьТоваров имеют хотя бы одно независимое измерение, связанное с серией (например, «СтатусПартии»).
2. Настройка прикладной логики для «Обратного потока»: Создайте отдельный вид операции для документа «Возврат товаров» — «Возврат брака по дистрибьюторскому договору». Это позволит отличить простой возврат от возврата, генерирующего обязательство по оплате логистики.
3. Интеграция с сервисом «Управление заказами дистрибьютора»: Используйте HTTPСоединение и ЗаписьJSON для отправки пакетов с пересортицей. Метод ВызватьHTTPМетод позволит выполнять не только GET/POST, но и PUT для обновления статусов возврата.
4. Тестирование сценария «Пересортица при FBO»: Создайте документ «Распределение товаров» (через // через реальный API ИТС), который фиксирует факт перевода права собственности от вендора к дистрибьютору без физического перемещения.

Предупреждение: Никогда не делайте «массовое проведение непроведенных документов» для исправления взаиморасчетов в дистрибьюции. Одна ошибка в дате акта сверки — и вы получите кассовый разрыв, который аудиторы найдут через 3 месяца. Используйте РежимЗаписиДокумента.Проведение только в рамках фоновых заданий с блокировками.

Типичные ошибки и их последствия

Опыт внедрения автоматизации дистрибьюции в компаниях с оборотом от 500 млн руб/мес показывает, что самые дорогие ошибки — не технические, а методологические.

Ошибка 1: «Смешивание потоков годного товара и брака в одном документе»

Последствие: в конце отчетного периода система «видит», что товар A числится на складе дистрибьютора, но фактически это брак, который подлежит утилизации. Бухгалтерия начисляет НДС по ставке 22% (согласно действующему налоговому законодательству) на всю сумму, хотя обязательств по реализации брака нет.

Решение: Создайте два вида номенклатуры с разными характеристиками: ТоварА_Годный и ТоварА_Брак. Используйте НайтиПоНаименованию для быстрого выбора при возврате.

Ошибка 2: «Игнорирование временных меток в регистрах при интеграции»

Когда вы отправляете HTTP-запрос на сервер распределительного центра (dist.1c.ru), ответ может прийти с задерж