При интеграции кассового программного обеспечения или загрузке данных из внешних систем (например, из старых конфигураций вроде ТИС или ОФД) в 1С:Бухгалтерия 3.0 мы часто сталкиваемся с ситуацией, которая на первый взгляд кажется нелогичной ошибкой программы. Речь идет о невозможности провести документ ОтчетОРозничныхПродажах, если один и тот же единственный экземпляр товара был продан, возвращен и снова продан в течение одной смены.
Давайте разберем эту проблему подробно, выясним причины поведения платформы и найдем оптимальные пути решения, которые удовлетворят и требования программы по контролю остатков, и требования аудиторов по корректному расчету НДС и УСН.
Рассмотрим ситуацию на конкретном примере, с которым столкнулся автор вопроса. У нас есть следующие вводные данные:
При загрузке этих данных в документ ОтчетОРозничныхПродажах (ОРП) система заполняет две табличные части:
При попытке провести такой документ 1С выдает ошибку: "Не списано 1 шт товара..., на остатке 1 шт". Почему так происходит, ведь математически (1 + 1 - 1) мы укладываемся в остаток?
Чтобы понять причину ошибки, заглянем "под капот" алгоритма проведения. Важно понимать, что документ ОтчетОРозничныхПродажах в типовых конфигурациях обрабатывается не как хронологическая последовательность чеков, а как сводная операция.
Алгоритм работает следующим образом:
ТоварыНаСкладах) и видит, что на начало момента времени документа доступна только 1 шт.Система не "сворачивает" продажи и возвраты внутри одного документа до момента записи движений. Она требует, чтобы на складе было достаточно товара для обеспечения всех продаж, указанных в документе, игнорируя тот факт, что часть товара вернется в этом же документе.
Самое очевидное решение — математически свернуть продажи. Если продали 2 и вернули 1, то по факту продана 1. Можно оставить в ОРП только одну строку продажи. Раньше (без НДС) так часто и делали.
Однако, если организация является плательщиком НДС, такой подход вызывает вопросы у аудиторов и методологов учета. Согласно требованиям (особенно в свете ФФД 1.05 и работы с онлайн-кассами):
Если мы просто удалим строки продаж и возвратов, мы занизим обороты в Книге продаж и Книге покупок. Сумма налога к уплате (сальдо) может остаться верной, но сами обороты будут искажены, что является нарушением правил заполнения декларации по НДС.
Другой популярный "быстрый" способ — отключить контроль отрицательных остатков в настройках Администрирование - Проведение документов.
Если мы это сделаем, документ проведется. Регистры НДС сформируются. Но возникнет серьезная проблема для плательщиков УСН "Доходы минус Расходы".
Для признания расходов по товарам в УСН должны быть выполнены три условия:
Когда мы отключаем контроль и продаем "в минус" (продаем 2-ю штуку, которой нет на остатке), разрывается цепочка партионного учета. Система не знает, какую партию мы продаем. Последующий возврат (в том же документе или позже) технически закроет минус по количеству, но регистр РасходыПриУСН часто не может корректно "склеить" этот разрыв без перепроведения в правильной хронологии. В результате: товар продан, оплачен, но в КУДиР расход не попадает.
Рассмотрим правильные способы обхода этого ограничения, которые позволят сохранить корректность учета.
Если вы загружаете данные программно, самым надежным методом будет разделение одного большого отчета за смену на несколько документов.
Алгоритм действий:
ОтчетОРозничныхПродажах, в который включаете первую продажу (1 шт.).В случае с "Продали 1 - Вернули 1 - Продали 1", идеально, если возврат будет оформлен отдельным документом (см. Способ 2), который по времени стоит между двумя продажами. Если всё делать через ОРП, то придется создавать несколько отчетов за смену, чтобы в каждом из них количество продаж не превышало текущий остаток.
В типовой конфигурации вкладка "Возвраты" в ОРП исторически предназначалась для возвратов товаров, проданных в предыдущие дни. Возвраты текущей смены часто обрабатывались как аннулирование чека.
Чтобы обойти блокировку остатков, вынесите возвраты из ОРП в отдельный вид документа.
Как это реализовать:
ОтчетОРозничныхПродажах оставляем только фактические продажи, которые обеспечены остатком. Если остатка не хватает для второй продажи, значит, нам нужно, чтобы возврат прошел раньше второй продажи.ВозвратTovarovOtPokupatelya (с видом операции "Товары").Этот метод трудоемкий при ручном вводе, но при автоматической загрузке он дает наиболее корректный результат и для НДС, и для УСН, и для складского учета.
Если разбивать отчеты невозможно (например, жесткие требования к соответствию Z-отчету), можно использовать временную "техническую" позицию или комплектацию, но это требует осторожности.
Суть метода: утром виртуально увеличить остаток товара (например, документом Оприходование или Комплектация из "воздуха"), провести ОРП, а вечером сторнировать излишек. Однако, как верно заметили участники обсуждения, этот метод не рекомендуется, так как:
Проблема не в ошибке 1С, а в строгой логике проведения документов: программа сначала списывает всё, что вы хотите продать, и только потом приходует возвраты.
Для корректного решения, чтобы "и волки были сыты (Аудиторы с НДС), и овцы целы (КУДиР УСН)", необходимо отказаться от попытки впихнуть невпихуемое в один документ и разнести операции по времени.
Если вы программист и пишете загрузку:
// Псевдокод логики разделения
Если ТекущийОстаток < КоличествоПродажВЧеке Тогда
// 1. Создать документ на доступный остаток
// 2. Создать документ Возврата (если он был в цепочке раньше)
// 3. Создать новый документ Продажи на появившийся остаток
КонецЕсли;
Наиболее чистым методологически вариантом является использование комбинации документов ОтчетОРозничныхПродажах (только для продаж) и ВозвратТоваровОтПокупателя (для возвратов), выстроенных в правильной хронологической последовательности в течение дня.