← На главную

Каждый специалист, работавший с конфигурацией «1С:Управление торговлей, редакция 10.3» (или аналогичными решениями на обычных формах, такими как УПП 1.3 и КА 1.1), неизбежно сталкивался с предупреждением системы: «Не списано по партиям...» при проведении документов реализации или списания. Эта ошибка блокирует корректное формирование себестоимости и делает невозможным получение точной финансовой отчетности.

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

Понимание архитектуры учета: почему «складской» остаток не равен «партионному»

Для начала проанализируем ключевую особенность архитектуры «1С:Управление торговлей 10.3». Количественный учет товаров на складах и партионный (стоимостной) учет ведутся в разных регистрах накопления:

1. Физическое количество товара хранится в регистре ТоварыНаСкладах (или ТоварыВРознице).
2. Партионный учет (себестоимость, документы прихода) ведется в регистре ПартииТоваровНаСкладах.

Когда вы формируете стандартный отчет «Ведомость по товарам на складах», программа берет данные из первого регистра. Товар там действительно может числиться в достаточном количестве. Однако при проведении документа списания система обращается ко второму регистру — ПартииТоваровНаСкладах. Если по нему остатка нет или он отличается по аналитическим признакам, проведение документа завершается ошибкой.

Рассмотрим детально основные причины такого расхождения.

Причина 1. Несовпадение аналитических признаков партии

Система ищет подходящую партию по жесткому набору измерений. Если хотя бы один параметр в документе списания отличается от параметров документа поступления, списание не произойдет. Проверим следующие разрезы:

• Организация. Товар мог быть оприходован на «Организацию А», а продается от лица «Организации Б». Если в информационной базе не настроена схема «Интеркампани» (которая в УТ 10.3 полноценно не автоматизирована «из коробки» без дополнительных обработок), система не спишет чужую партию.
• Склад. Если в учетной политике базы включен флаг «Вести партионный учет по складам», то система требует наличия партии строго на том складе, который указан в реализации. Если флаг отключен, партии списываются «в целом по компании», но включение этого флага задним числом мгновенно ломает всю последовательность.
• Характеристика и Серия номенклатуры. Часто пользователи визуально видят одинаковые наименования серий, но физически это разные элементы справочника СерииНоменклатуры (дубли). Проанализируем это с помощью отчета.
• Качество. По умолчанию товары приходуются с качеством «Новый». Если в документе списания ошибочно указано качество «Брак» (или наоборот), партия не спишется.
• Статус партии. Товар может числиться со статусом «Купленный», «Принятый на комиссию» или «На double-distrib». Убедимся, что мы пытаемся списать товар с тем же статусом, под которым он пришел.

Причина 2. Обособленный учет по заказам (Резервы)

Если в настройках параметров учета или в учетной политике включен обособленный учет товаров по заказам, то партии жестко привязываются к конкретным документам ЗаказПокупателя или ЗаказПоставщику.

Если товар оприходован под «Заказ №1», то попытка списать его прямой продажей (без указания заказа) или под «Заказ №2» вызовет ошибку списания партий. Для системы этого товара «нет в свободном остатке», он зарезервирован.

Причина 3. Хронологические коллизии (проведение «в пределах секунды»)

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

При неоперативном проведении документов задним числом система может «пропустить» операцию списания (если разрешено списание в минус), но при последующем восстановлении последовательности партионного учета вы получите ошибку.

Причина 4. Рассинхронизация итогов (технический сбой СУБД)

Иногда физические записи в таблице движений регистров существуют, но из-за сбоев платформы, динамических обновлений конфигурации или некорректной работы СУБД повреждаются таблицы итогов регистров накопления. В этом случае отчеты могут показывать остаток, но виртуальная таблица Остатки, к которой обращается запрос проведения документа, возвращает пустой результат.

---

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

Выясним причину сбоя и устраним ее с помощью методических и технических приемов.

Шаг 1. Проверяем детальные остатки по партии с помощью отчета

Не полагайтесь на стандартную «Ведомость по товарам на складах». Нам нужен специализированный отчет. Перейдем в меню: Отчеты -> Запасы (склад) -> Ведомость по партиям товаров на складах.

Настроим группировки отчета следующим образом:

1. Номенклатура
2. Склад
3. Характеристика номенклатуры
4. Серия номенклатуры
5. Документ оприходования (партия)
6. Статус партии
7. Заказ

Установим период отчета строго по секунду проведения проблемного документа. Например, если документ реализации проводится 15.05.2023 14:30:15, то отчет формируем на эту же дату и время.

Сравним выведенные данные с реквизитами вашей реализации. Вы обязательно увидите расхождение в одном из полей (например, в базе висит партия с пустой серией, а в реализации выбрана конкретная серия).

Шаг 2. Корректировка времени документов

Если в ходе анализа Шага 1 выяснилось, что партия прихода существует в тот же день, но время документа поступления позже времени документа реализации (или совпадает секунда в секунду):

• Изменим время документа поступления, сделав его более ранним (например, на начало дня или на 1 минуту раньше реализации).
• Перепроведем по цепочке сначала поступление, а затем реализацию.

Шаг 3. Анализ и исправление дублирующихся элементов

Если вы обнаружили, что в отчете по партиям и в документе реализации указаны визуально одинаковые серии, проверим их на предмет дублирования:

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

Шаг 4. Восстановление последовательности и партионный учет

В УТ 10.3 учетная политика может разрешать проведение документов без партий в оперативном режиме с последующим расчетом себестоимости. Если это ваш случай, то при оперативной работе партии не списываются.

Для исправления ситуации выполним регламентную процедуру:

1. Перейдем в меню: Сервис -> Универсальные механизмы -> Проведение по партиям.
2. Укажем период и организацию.
3. Запустим обработку. Она последовательно восстановит границу партионного учета и спишет все зависшие партии.

Шаг 5. Техническое обслуживание таблиц итогов (при подозрении на сбой СУБД)

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

Для файловой или клиент-серверной базы выполним следующие шаги в режиме Конфигуратора:

1. Создадим резервную копию базы данных (обязательно!).
2. Перейдем в меню: Администрирование -> Тестирование и исправление...
3. Установим флаг напротив пункта «Пересчет итогов» (остальные флаги можно снять для ускорения процесса).
4. Нажмем кнопку «Выполнить».

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

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