Как решить проблему с исчезновением возвратов в одну смену при обмене между 1С:Розница и 1С:Управление торговлей

Программист 1С v8.3 (Управляемые формы) 1С:Управление торговлей Управленческий учет Торговля и дистрибуция
← На главную

При совместной работе конфигураций 1С:Розница 2.2 и 1С:Управление торговлей 11.3 пользователи часто сталкиваются с неприятной проблемой: после выполнения обмена данными розничные продажи в управляющей базе (УТ) оказываются завышенными, а остатки товаров на складах не сходятся. Выясняется, что товары, возвращенные покупателями в кассовую смену продажи, бесследно «исчезают» при переносе данных.

В этой статье мы подробно разберем, почему возникает эта проблема, как устроена логика учета розничных возвратов в различных конфигурациях 1С, и рассмотрим практические варианты решения этой технической коллизии.

В чем суть проблемы и почему «теряются» возвраты

Рассмотрим стандартную цепочку действий кассира в розничной точке. В течение смены происходят как продажи товаров, так и их возвраты. Возвраты, оформленные в пределах одной кассовой смены (так называемые возвраты «день в день»), фиксируются на кассе документом Чек ККМ на возврат.

При закрытии кассовой смены в программе 1С:Розница формируется итоговый документ Отчет о розничных продажах (ОРП). Внутри этого документа на стороне Розницы присутствуют две ключевые табличные части:

  1. Товары — сюда попадают все проданные за смену позиции (без уменьшения на величину возвратов).
  2. Возвращенные товары — на этой отдельной вкладке фиксируются все возвраты, оформленные в течение этой же смены.

При выполнении синхронизации с 1С:Управление торговлей 11.3 документ Отчет о розничных продажах переносится в УТ. Однако в структуре ОРП на стороне УТ 11.3 исторически отсутствует табличная часть для возвращенных товаров. Стандартные правила конвертации данных просто переносят табличную часть Товары «как есть», полностью игнорируя вкладку возвратов. В результате в УТ фиксируется «грязная» выручка (без учета возвратов), а возвращенный товар не восстанавливается на остатках склада.

Анализируем методологию учета розничных возвратов в 1С

Согласно методологии учета 1С, возвраты, произведенные в одну смену с продажей, по сути являются отменой операции продажи. Это означает, что итоговые показатели за смену должны автоматически «сворачиваться»:

Итоговая продажа = (Количество проданного товара) - (Количество возвращенного товара)

Если за смену было продано 5 штук определенного товара, а 2 штуки вернули в ту же смену, то в Отчете о розничных продажах в УТ должна отразиться продажа только 3 штук. Если же товар был возвращен в объеме, превышающем продажи этой смены (например, возврат за прошлую смену), то современные версии программ допускают указание отрицательного количества или требуют оформления отдельного документа возврата.

В «1С:Розница» табличная часть Возвращенные товары была создана исключительно для аналитики (чтобы менеджеры могли видеть структуру возвратов внутри смены). Однако правила обмена «из коробки» между Розницей 2.2 и УТ 11.3 не выполняют автоматическую свертку этих таблиц при выгрузке, что и приводит к ошибкам учета.

Ниже мы разберем три практических способа устранения этой проблемы.

Решение 1: Модификация правил обмена данных (путь программиста)

Самым надежным и автоматизированным решением является корректировка правил конвертации данных (ПКД). Нам необходимо сделать так, чтобы перед отправкой документа Отчет о розничных продажах из Розницы в УТ происходила программная свертка табличных частей.

Для реализации этого алгоритма в правилах обмена (в обработчике события Перед выгрузкой для документа ОРП) необходимо прописать код, который уменьшит показатели в ТЧ Товары на количество и сумму из ТЧ Возвращенные товары.

Проанализируем пример кода, который решает эту задачу:


// Сворачиваем возвраты с продажами перед отправкой в УТ
ТаблицаТовары = ЭтотОбъект.Товары.Выгрузить();
ТаблицаВозвраты = ЭтотОбъект.ВозвращенныеТовары.Выгрузить();

Для Каждого СтрокаВозврата Из ТаблицаВозвраты Цикл
    ПараметрыПоиска = Новый Структура;
    ПараметрыПоиска.Вставить("Номенклатура", СтрокаВозврата.Номенклатура);
    ПараметрыПоиска.Вставить("Характеристика", СтрокаВозврата.Характеристика);
    
    НайденныеСтроки = ТаблицаТовары.НайтиСтроки(ПараметрыПоиска);
    
    Если НайденныеСтроки.Количество() > 0 Тогда
        Для Каждого СтрокаТовара Из НайденныеСтроки Цикл
            // Вычисляем объем свертки
            КоличествоДляВычитания = Мин(СтрокаТовара.Количество, СтрокаВозврата.Количество);
            
            СтрокаТовара.Количество = СтрокаТовара.Количество - КоличествоДляВычитания;
            СтрокаТовара.Сумма = СтрокаТовара.Сумма - (КоличествоДляВычитания * СтрокаТовара.Цена);
            
            // Если рассчитывается автоматическая скидка или НДС, их также нужно пропорционально уменьшить
            Если СтрокаТовара.Количество > 0 Тогда
                СтрокаТовара.СуммаАвтоматическойСкидки = СтрокаТовара.СуммаАвтоматическойСкидки * (СтрокаТовара.Количество / (СтрокаТовара.Количество + КоличествоДляВычитания));
            Иначе
                СтрокаТовара.СуммаАвтоматическойСкидки = 0;
            КонецЕсли;
            
            СтрокаВозврата.Количество = СтрокаВозврата.Количество - КоличествоДляВычитания;
            
            Если СтрокаВозврата.Количество = 0 Тогда
                Прервать; // Возврат полностью учтен
            КонецЕсли;
        КонецЦикла;
    КонецЕсли;
КонецЦикла;

// Удаляем из выгружаемой таблицы товары с нулевым количеством
Индекс = ТаблицаТовары.Количество() - 1;
Пока Индекс >= 0 Цикл
    СтрокаТовара = ТаблицаТовары[Индекс];
    Если СтрокаТовара.Количество <= 0 Тогда
        ТаблицаТовары.Удалить(СтрокаТовара);
    КонецЕсли;
    Индекс = Индекс - 1;
КонецЦикла;

// Записываем свернутую таблицу обратно в объект для выгрузки
ЭтотОбъект.Товары.Загрузить(ТаблицаТовары);
ЭтотОбъект.ВозвращенныеТовары.Очистить(); // Очищаем возвраты, так как они уже учтены

Данный код находит совпадения по номенклатуре и характеристике, уменьшает количество проданного товара на количество возвращенного и очищает вкладку возвратов. В УТ придет абсолютно корректный «чистый» отчет.

Решение 2: Использование внешней обработки свертки в Рознице

Если вы не хотите вносить изменения в правила обмена (которые могут обновиться при очередном обновлении конфигурации), можно использовать внешнюю обработку. Ее суть заключается в том, что перед каждым сеансом обмена в «1С:Розница» запускается групповая свертка документов Отчет о розничных продажах за открытый период.

Обработка работает по следующему алгоритму:

  1. Находит все проведенные документы Отчет о розничных продажах за выбранный период.
  2. Для каждого документа программно сопоставляет таблицы Товары и Возвращенные товары.
  3. Производит математическое вычитание возвратов из продаж прямо в информационной базе Розницы.
  4. Очищает ТЧ Возвращенные товары.
  5. Перепроводит документ.

После работы такой обработки стандартный обмен перенесет в УТ уже скорректированные документы без потери данных.

Решение 3: Изменение бизнес-процесса оформления возвратов (без программирования)

Если у вас нет штатного программиста 1С, проблему можно решить организационным путем, изменив регламент работы кассиров в Рознице.

Вместо оформления возврата через интерфейс РМК (режим кассы «день в день», который делает движения по ТЧ Возвращенные товары), кассир может делать возврат на основании ранее пробитого чека из архива, оформляя полноценный документ Возврат товаров от покупателя.

Документы Возврат товаров от покупателя (в отличие от чеков возврата в ОРП) без проблем переносят данные при обмене и создают в 1С:УТ документ Возврат товаров от клиента. Минус этого подхода — усложнение работы кассира на кассе и увеличение времени обслуживания покупателя.

Как эта проблема решена в современных версиях 1С (УТ 11.5 и Розница 3.0)

Проанализируем, как фирма «1С» доработала этот механизм в современных релизах программных продуктов. В актуальных версиях архитектура обмена была полностью пересмотрена:

Если вы до сих пор работаете на устаревших версиях УТ 11.3 и Розница 2.2, мы настоятельно рекомендуем рассмотреть возможность обновления конфигураций до актуальных версий, что позволит раз и навсегда избавиться от подобных архитектурных ошибок учета.

← На главную