Возврат товаров от розничного покупателя — это стандартная торговая операция, которая, тем не менее, часто вызывает головную боль у практикующих бухгалтеров, товароведов и программистов 1С. Особенно остро эта проблема встает при использовании внешних кассовых программ, таких как Frontol (ККМ Offline), интегрированных с конфигурацией 1С:Розница. Пользователи нередко сталкиваются с ситуацией, когда по данным кассы возврат прошел, а в товароучетной программе 1С остатки на склады не вернулись, движения по регистрам отсутствуют, а финансовая отчетность начинает «плыть».
В этой статье мы подробно разберем, как устроен механизм возвратов в конфигурации 1С:Розница 2.2 (и более поздней 2.3), проанализируем разницу между возвратами «день в день» и возвратами прошлых смен, выясним причины сбоев при интеграции со сторонним кассовым ПО и найдем оптимальные пути решения этих проблем.
Для начала разберем, как должна работать система, если кассиры используют стандартное рабочее место кассира (РМК) в самой 1С:Розница. Здесь поведение программы строго разделено на два сценария в зависимости от даты совершения исходной покупки.
Сценарий 1. Возврат товара в течение одной и той же смены (день в день)
Если покупатель возвращает товар до закрытия кассовой смены, в которой была совершена продажа, система производит операцию сторнирования:
ОтчетОРозничныхПродажах (далее — ОРП).Сценарий 2. Возврат товара, купленного в другую (прошлую) смену
Когда покупатель приносит товар, купленный вчера или в любой другой прошлый день, смена по той продаже уже закрыта, а данные зафиксированы в ОРП прошлых периодов. Изменять прошлые документы задним числом система не имеет права. Поэтому возврат оформляется иначе:
ТоварыНаСкладах, тем самым возвращая позицию на баланс склада. Также корректируется выручка текущего дня.Проанализируем ситуацию, когда в качестве кассового фронт-офиса используется программа Frontol. Обмен данными в этом случае происходит через текстовые файлы транзакций (формат АТОЛ). При закрытии смены Frontol выгружает файл, который загружается в 1С с помощью встроенного механизма «Загрузка данных в ККМ Offline».
Именно на этом этапе часто происходит сбой. Типовой обработчик загрузки транзакций из Frontol в 1С:Розница не всегда корректно интерпретирует транзакции возврата из прошлых смен. Вместо того чтобы создать в документе ОтчетОРозничныхПродажах строку с отрицательным количеством в табличной части Товары (как это происходит в штатном РМК), обработка просто помещает номенклатуру на вкладку Возвращенные товары.
Как мы уже выяснили выше, вкладка Возвращенные товары в ОРП является **чисто информационной**. Она не делает движений по регистрам остатков товаров и не возвращает номенклатуру на склад! В результате мы получаем критическое расхождение: деньги покупателю через ККМ выданы, касса сошлась, а товар на склад в программе 1С не вернулся.
Для исправления этой ошибки программисту 1С необходимо доработать модуль загрузки отчетов ККМ Offline (лучше всего сделать это через механизм расширений, чтобы сохранить конфигурацию на поддержке). Наша задача — заставить систему правильно распределять транзакции возвратов прошлых дней.
Рассмотрим пример кода, который анализирует транзакции загрузки и принудительно создает отрицательные строки в ТЧ Товары, если возвращенный товар не продавался в текущую смену:
// Фрагмент алгоритма обработки транзакций при загрузке из Frontol
Процедура ОбработатьТранзакциюВозврата(ТекущаяТранзакция, ТаблицаТоваровОРП) Экспорт
// Ищем, продавался ли этот товар в текущей загружаемой смене
ПараметрыОтбора = Новый Структура;
ПараметрыОтбора.Вставить("Номенклатура", ТекущаяТранзакция.Номенклатура);
ПараметрыОтбора.Вставить("Характеристика", ТекущаяТранзакция.Характеристика);
НайденныеСтроки = ТаблицаТоваровОРП.НайтиСтроки(ПараметрыОтбора);
Если НайденныеСтроки.Количество() > 0 Тогда
// Сценарий "День в день": уменьшаем количество продажи
СтрокаПродажи = НайденныеСтроки[0];
СтрокаПродажи.Количество = СтрокаПродажи.Количество - ТекущаяТранзакция.Количество;
СтрокаПродажи.Сумма = СтрокаПродажи.Сумма - ТекущаяТранзакция.Сумма;
// Если количество стало равным нулю, строку можно удалить,
// но лучше оставить для аналитики с нулевым количеством
Иначе
// Сценарий "Прошлые смены": добавляем строку с минусом
НоваяСтрока = ТаблицаТоваровОРП.Добавить();
ЗаполнитьЗначенияСвойств(НоваяСтрока, ТекущаяТранзакция);
НоваяСтрока.Количество = -ТекущаяТранзакция.Количество;
НоваяСтрока.Сумма = -ТекущаяТранзакция.Сумма;
НоваяСтрока.Цена = ТекущаяТранзакция.Цена;
КонецЕсли;
КонецПроцедуры
Данный алгоритм гарантирует, что любой возврат товара из прошлых смен, по которому сегодня не было продаж, отразится в ОРП в виде отрицательной строки и сделает правильное движение «Приход» на склад.
Еще одна частая проблема, упомянутая практикующими специалистами, — это проведение возвратов без привязки к конкретному документу продажи (так называемый «возврат без основания»). Это происходит, когда кассир ленится искать чек продажи в базе или покупатель потерял чек, и товар возвращают просто по текущей розничной цене.
Выясним, к каким последствиям это приводит:
Для предотвращения подобных ситуаций настоятельно рекомендуем выполнить следующие настройки в 1С:Розница:
Если вы хотите полностью исключить проблемы с отрицательными остатками в ОРП и облегчить последующую синхронизацию с 1С:Бухгалтерия предприятия, методисты фирмы 1С рекомендуют оформлять возвраты прошлых дней через бэк-офисные документы, а не через РМК кассира.
Давайте разберем эту схему по шагам:
ВозвратТоваровОтПокупателя (раздел Продажи). В качестве основания обязательно указывается исходный документ продажи (ОРП или Чек прошлых периодов). Это позволяет программе точно определить себестоимость и вернуть товар на склад по правильной партии.РасходныйКассовыйОрдер (РКО) — если выдаются наличные деньги из главной кассы.ЭквайринговаяОперация с видом «Возврат покупателю» — если деньги возвращаются на банковскую карту клиента.Этот способ является наиболее чистым с точки зрения методологии бухгалтерского учета и полностью исключает появление «минусов» в ОРП, которые часто вызывают ошибки проведения при обмене с бухгалтерией (например, знаменитую ошибку в 1С:БП 3.0: «Сумма безналичных оплат превышает сумму выручки»).