Почему в 1С:Бухгалтерия 3.0 при возврате товаров возникает ошибка «Реализовано на 1 единицу меньше, чем возвращается»?

Ситуация, когда при проведении документа Возврат товаров от покупателя система выдает ошибку о нехватке реализованного товара, встречается довольно часто, особенно в конфигурации 1С:Бухгалтерия предприятия 3.0 (КОРП и ПРОФ). Самое неприятное в этой ошибке — это ее очевидная нелогичность: в документе реализации числится ровно то количество, которое мы пытаемся вернуть, аналитика совпадает, а возврат все равно не проводится. Рассмотрим детально, почему это происходит и как решить проблему.

Анализ механизма проверки отгрузки

Для начала разберем, как программа «понимает», сколько товара было отгружено. В отличие от простых регистров остатков, документ возврата в БП 3.0 выполняет сложный запрос к регистру бухгалтерии Хозрасчетный. Система пытается сопоставить данные текущего возврата с данными первичной отгрузки (Реализации), учитывая при этом все промежуточные движения по этой номенклатуре.

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

ВЫБРАТЬ
    ХозрасчетныйДвиженияССубконто.СубконтоКт1 КАК Номенклатура,
    ХозрасчетныйДвиженияССубконто.СчетКт КАК СчетУчета,
    НАЧАЛОПЕРИОДА(ХозрасчетныйДвиженияССубконто.Период, МЕСЯЦ) КАК Период,
    -ХозрасчетныйДвиженияССубконто.КоличествоКт КАК КоличествоОтгружено,
    ХозрасчетныйДвиженияССубконто.Организация
ИЗ
    РегистрБухгалтерии.Хозрасчетный.ДвиженияССубконто(
        &НачМесяцаРеализации,
        &КонДата,
        Организация = &Организация
        И ПодразделениеКт = &ПодразделениеОтгрузки
        И СчетКт В (&СчетКтНеПартионный)
        И НеКорректироватьСтоимостьАвтоматически
        И КоличествоКт < 0
        И СубконтоКт1 В (&Товары)
    ) КАК ХозрасчетныйДвиженияССубконто

Как мы видим, запрос накладывает жесткие условия на движения по кредиту счетов учета (например, 41.01). Если хотя бы один параметр (подразделение, склад или счет учета) в реализации и возврате отличается, запрос вернет 0, и мы получим ошибку.

Причина 1: Программная ошибка в конкретных релизах

Если вы столкнулись с этой проблемой, первым делом проверьте номер релиза вашей конфигурации. В истории обновлений 1С:Бухгалтерия 3.0 (начиная с релиза 3.0.115.19 и вплоть до 3.0.119.x) наблюдалась программная ошибка. Система некорректно рассчитывала остатки проданных товаров по счетам с партионным учетом. Если ваша база находится на этих релизах, рекомендуется обновиться до актуальной версии (не ниже 3.0.120), где этот механизм был переработан.

Причина 2: Реквизит «Не корректировать стоимость автоматически»

Обратим внимание на условие запроса И НеКорректироватьСтоимостьАвтоматически. Этот реквизит напрямую влияет на то, увидит ли программа вашу реализацию как «доступную» для возврата. Разберем ситуацию подробнее:

1. Если вы создали Возврат товаров от покупателя, программа проверяет, был ли этот товар уже возвращен ранее.
2. Если в базе уже есть возвраты по этой же номенклатуре в этом же периоде, система может «перепутать» партии, если в одном из документов стоит признак ручной корректировки стоимости.
3. При переходе с версии 2.0 на 3.0 или при некорректном переносе данных этот реквизит в старых документах реализации (июньских, как в нашем примере) может быть не заполнен, что сбивает алгоритм расчета в августе.

Что нужно сделать: Проверьте в консоли запросов или через групповое изменение реквизитов значение поля НеКорректироватьСтоимостьАвтоматически в движениях документа-основания и предыдущих возвратов. Если оно установлено в значение Ложь, а система ожидает Истина (или наоборот), это и будет причиной блокировки проведения.

Причина 3: Межпериодные расхождения и «Закрытие месяца»

Проанализируем ситуацию, когда реализация была в июне, а возврат — в августе. Если между этими датами (в июле) проводилась Корректировка реализации или иные операции, изменяющие состояние счета 90.02 (Себестоимость продаж), система может посчитать, что остаток товара по данной партии уже исчерпан.

Также важно состояние регламентной операции Корректировка стоимости номенклатуры. Если июнь и июль не закрыты окончательно или после их закрытия были внесены правки «задним числом», регистр Хозрасчетный может содержать неактуальные данные о количестве отгруженного товара в разрезе субконто.

Пошаговый алгоритм решения проблемы

Рассмотрим последовательность действий для исправления ошибки:

1. Проверка аналитики: Откройте проводки документа Реализация (акты, накладные) и сравните их с проводками, которые пытается сделать Возврат товаров. Убедитесь, что Счет учета, Склад и Подразделение совпадают до символа. Особое внимание уделите субконто «Партии» (если ведется партионный учет).
2. Проверка цепочки документов: Воспользуйтесь отчетом Карточка счета по 41 счету с фильтром по конкретной номенклатуре. Посмотрите, не было ли других возвратов по этой же реализации. Помните, что программа не позволит вернуть больше, чем было отгружено по конкретному документу-основанию.
3. Тестовое проведение без основания: Попробуйте временно очистить поле Документ реализации в табличной части возврата. Если документ проведется — значит, проблема именно в связи «Реализация — Возврат» и остатках по этой связи.
4. Перепроведение документов: Попробуйте перепровести реализацию в июне и все последующие документы по этой номенклатуре. Иногда это помогает обновить движения в регистре бухгалтерии, которые «подхватит» запрос возврата.
5. Использование расширения или исправление кода: Если обновление конфигурации невозможно, можно воспользоваться расширением, которое корректирует запрос в общем модуле УчетТоваров, убирая избыточные проверки на НеКорректироватьСтоимостьАвтоматически или уточняя поиск партий.

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