Восстановление, заполнение, исправление серий в отгружаемых товарах для КА 2.5, УТ 11.5, ERP 2.5

В КА 2.5 по расходным ордерам накапливались отрицательные остатки по сериям. Списание уходило «не туда», в минус. Нужно было исправить уже проведённые документы — заменить серию в проблемных строках на корректную из остатков. Релевантные задаче темы:

«Автозакрытие отрицательных остатков»
«Автозаполнение серий»
«Автоматическое выравнивание серий»
«Восстановление серий FEFO»
«Выравнивание серий»
«Заполнение серий по остаткам номенклатуры»
«Заполнение серий в документах»
«Заполнения табличной части сериями»
«Избавление от отрицательных остатков по сериям»

«Исправление ошибок по сериям»
«Исправление серий в документе»
«Исправление серий отгружаемых товаров»
«Исправление серий товаров на складах»
«Минусы по сериям»
«Отрицательные остатки серий»
«Списание оприходование серий»
«Пересорт серий»
«Подбор серий»

Все это по заголовку подходило, но по содержанию - ничего не подошло.

Мой критерий отбора — что подходило:

По ходу поиска сложился жёсткий фильтр:

Проблема

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

Например:

• На складе лежит серия от 01.07.26 — 1 000 шт.

• Есть также серия от 01.08.26 — 500 шт.

• Оператор в расходном документе указывает 01.07.26, хотя фактически списывается 01.08.26.

Результат:

• По серии 01.07.26 — отрицательный свободный остаток (минус).

• По серии 01.08.26 — не списанный излишек.

Остаток по номенклатуре в целом верный, но распределён между сериями неправильно. Такие ошибки типичны для организаций с большим объёмом отгрузок и ведут к:

• Некорректной себестоимости.

• Проблемам с маркировкой (для подакцизных и маркируемых товаров).

• Искажению отчётности по срокам годности.

• Ручному поиску и правке документов задним числом.

Кому полезна обработка

• Компаниям с учётом по сериям (УТ 11, КА 2, ERP 2, УНФ 3).

• Складам с большим потоком расходных ордеров.

• Организациям с маркируемой продукцией (бытовая химия, косметика, БАДы, лекарства).

• Тем, кто регулярно сталкивается с «плавающими» минусами по сериям.

КАК ЭТО РАБОТАЕТ

Основная идея

Обработка не пытается перепровести все документы подряд. Она работает точечно:

1. Находит проблемные комбинации Склад + Номенклатура + Серия, где свободный остаток ушёл в минус.

2. Для каждой комбинации восстанавливает хронологию движений и находит точку перехода через ноль — момент, когда остаток стал отрицательным.

3. Регистратор этого перехода — документ-виновник, который списал лишнее по «неправильной» серии.

4. В найденном документе заменяет серию на другую, у которой на дату документа был достаточный свободный остаток (FIFO).

Пошаговая логика

Шаг 1. Поиск проблемных комбинаций

Запрос к регистру ТоварыНаСкладах.Остатки с фильтром ВНаличииОстаток - КОтгрузкеОстаток < 0. Отбираются только те комбинации, по которым были движения РасходныйОрдерНаТовары после даты запрета изменений.

Шаг 2. Пакетная загрузка движений

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

Шаг 3. Поиск перехода через ноль

Проходим по движениям в хронологическом порядке, накапливая свободный остаток. Момент, когда остаток перешёл из плюса в минус — искомая точка. Регистратор этой операции и есть документ-виновник.

Шаг 4. Формирование плана замен

Собираем уникальные документы-регистраторы. Для каждого:

• Сортируем по дате (или по весу — в режиме «Этап 1»).

• Проверяем соответствие ТЧ документа и движений регистра.

• Ищем FIFO-кандидата — другую серию той же номенклатуры с достаточным остатком на дату документа.

• Резервируем выбранного кандидата (чтобы он не был использован дважды для других комбинаций).

Шаг 5. Применение плана

Замена серии в ТЧ документа и перепроведение. В режиме Проверка — только вывод плана, без записи.

Ключевые защиты

• Двойная защита от записи в режиме «Проверка»: продолжение цикла + явная проверка перед Записать.

• Никаких ПолучитьОбъект() в фазе анализа — только запросы через ссылки.

• Резервирование кандидатов — исключает двойное использование одной серии.

ТРИ РЕЖИМА РАБОТЫ

1. Проверить (диагностика без записи)

• Один документ-виновник.

• Полный вывод: снимок минусов до/после, сравнение с предыдущим прогоном, промпт для нейросети.

• Ничего не записывается.

• Используется для аудита текущей ситуации.

2. Исправить (точечное исправление)

• Один документ по дате (самый ранний переход).

• С записью.

• Быстрая проверка эффекта на одном документе.

3. ИсправитьПакет (массовая обработка, N документов)

• N документов по дате за один прогон (N — из реквизита формы РазмерПакета).

• Пропускает документы без кандидатов и берёт следующие — это критично, иначе цикл застревает в первом «мёртвом» документе.

• Для массовой обработки.

Дополнительно: Этап 1 (приоритетный режим)

• Выбирает документ с наибольшим весом — числом созданных им переходов через ноль.

• Один документ может закрыть сразу несколько минусов.

• Рекомендуется, если в логе «Этапа 1» топ-1 документ имеет вес >= 2.

НОУ-ХАУ

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

Не ищем минус как таковой. Ищем момент его появления. Это даёт точное определение документа-виновника даже при сложной хронологии движений.

2. Детектор записи через файл-снимок

После каждого прогона в файл (временный каталог) сохраняется снимок минусов — перечень комбинаций и их остатков.

При следующем прогоне снимок читается и сравнивается с текущим. Разница показывает:

• 0 — записи между прогонами не было.

• +N — минус сократился на N единиц.

• -N — минус вырос (тревожный сигнал).

Это автономный детектор, не зависящий от внешних подсистем.

3. Встроенный анализ динамики

По каждому прогону выводится:

• ЗАКРЫТО — минус стал 0.

• УМЕНЬШИЛОСЬ — минус сократился по модулю.

• ОСТАЛОСЬ БЕЗ ИЗМЕНЕНИЙ — обработка не касалась.

• УВЕЛИЧИЛОСЬ — минус вырос (норма, если это переезд на правильную серию).

• НОВЫХ — новые минуса (норма, если общий минус падает).

С детализацией по каждой комбинации.

4. Промпт для нейросети

В конце режима «Проверка» в лог выводится готовый контекст — 10 пунктов с описанием задачи, логики и рекомендаций пользователю. Лог можно скопировать в DeepSeek / ChatGPT / Claude, и модель сразу поймёт ситуацию и даст рекомендации:

• Продолжать цикл или остановиться.

• Сменить режим.

• Прогнозировать количество прогонов.

• Идентифицировать неисправимые минуса.

Это уникальная фича — обработка не только сама формирует движения, но и сама формирует контекст для анализа ИИ.

5. Заполнение пустой серии для маркируемой продукции

Отдельная функция — заполнение пустой серии в ТЧ ОтгружаемыеТовары для номенклатуры с видом "...со сроком годности...". Работает напрямую с ТЧ документов, без обращения к регистрам.

Замечания из практики:

• «Переезды минуса» — норма (минус с неправильной серии переходит на правильную).

• Пропуск документов без кандидатов — обязателен, иначе цикл застревает.

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

ТРЕБОВАНИЯ

• Платформа: 1С:Предприятие 8.3.20 и выше.

• Конфигурации: КА 2.5, УТ 11.5, ERP 2.5 (аналогичные, с документом РасходныйОрдерНаТовары).

• Права: чтение регистра ТоварыНаСкладах, запись документа РасходныйОрдерНаТовары.

• Бэкап: обязательно перед первым запуском в режиме Исправить.

ОГРАНИЧЕНИЯ

• Обработка заменяет серию, но не создаёт приходы и не перепроводит всю цепочку документов. Если минус реальный (не было прихода) — он останется.

• Не работает для номенклатуры, не ведущейся по сериям.

• Требует, чтобы ТЧ соответствовала движениям регистра (иначе комбинация пропускается).

• Запускать не в часы пик (перепроведение документов блокирует пользователей).

Что дальше?

Что показывает отчёт

Одна и та же номенклатура AVK-346 с двумя сериями:

Итого по номенклатуре: 579 - 636 = -57.

Анализ

Проблема №1: минус по серии 01.02.26

По серии 01.02.26:

• Остаток был всего 3.

• Списано РасходныйОрдерНаТовары КА-01010507 60 единиц.

• Итог: -57 (минус).

Проблема №2: серия 01.09.25 закрылась в ноль

По серии 01.09.25:

• Приход 576.

• Списано в три документа по 576 единиц.

• Итог: 0 (нет остатка).

Что произошло по факту

Фактически отгружалось 57 единиц 01.02.26? Или 01.09.25?

Возможные сценарии:

A. Реально отгружали 01.02.26, но в документе КА-01010507 указали неверно — и списали 60, хотя на складе было только 3.

B. Реально отгружали 01.09.25, и оператор должен был поставить эту серию, но ошибся.

Почему обработка не исправила

Смотрим лог последнего прогона:

text

Найдено комбинаций: 17
Переходов найдено: 17
Отобрано документов: 0 из 9 (пропущено без кандидатов: 9)
Кандидатов найдено: 0
Элементов в плане: 0

Документ КА-01010507 от 29.09.2026 — в списке проблемных (создаёт переход через ноль для AVK-346 / 01.02.26).

Но кандидата нет — потому что:

• Серия 01.09.25 — остаток 0 на дату документа 29.09.2026. К тому времени она уже вся израсходована.

• Другой серии с остатком нет.

• НайтиFIFOКандидата не находит кандидата → пропуск.

Ключевая проблема логики

Обработка ищет кандидата на дату документа 29.09.2026. На эту дату серии 01.09.25 уже не было (израсходована на 576 единиц до этого). Логически всё верно — в момент отгрузки выбирать было нечего.

Почему это проблема в целом

Отчёт показывает итог -57 по номенклатуре. Но фактически:

• На склад пришло 576 единиц 01.09.25.

• Отгружено 576 единиц по документам.

• Ещё должно было быть отгружено 57 единиц — но они «потерялись» на бумаге.

Значит, в какой-то момент одна из отгрузок указала неверную серию. Возможно:

• КА-00866504 (первая отгрузка 36) — указали 01.09.25, но фактически отгружали 01.02.26 (на складе было 3).

• КА-00883735 (480) — серия верна.

• КА-00901176 (60) — серия верна.

• Итого: 36 + 480 + 60 = 576 — всё из 01.09.25. Но фактически на 01.09.25 было 576, а на 01.02.26 — 3.

Если реально 01.02.26 отгрузили 3, а остальные из 01.09.25** — **всё** **сходится**. **Но** **тогда** **откуда**-57**в**01.02.26`?

Гипотеза: КА-01010507 списал 60 единиц 01.02.26, хотя эта серия не должна была списываться (её не было на складе в таком количестве). Фактически отгружали 01.09.25.

Но на 01.09.25 уже 0 на момент 29.09.2026 — значит, пересортица случилась раньше (в КА-00866504 от 01.09.2026).

Что делать

Вариант A: Использовать логику «сводный остаток по номенклатуре»

Идея: если по серии 01.02.26 минус 57, но по другой серии 01.09.25 был излишек (пусть даже сейчас 0) — можно перенести расход с 01.02.26 на 01.09.25 в более раннем документе, чтобы итог по номенклатуре сошёлся.

Но — это уже другая задача: не «найти кандидата с остатком», а «перераспределить расход между сериями в цепочке документов».

Вариант B: Расширить поиск кандидата

Искать кандидата не только на дату документа, но и с учётом будущих приходов.

Пример: 01.09.25 на 29.09.2026 = 0, но позже (например, в октябре) приходил товар с этой серией. Тогда можно зачесть расход в 01.09.25, даже если на момент документа остатка не было.

Но — это опасно: мы создаём минус в другом периоде.

Вариант C: Сквозная пересборка движений по номенклатуре

Идея: рассматривать номенклатуру целиком, не по сериям. Перераспределить расход так, чтобы все серии были >= 0.

Алгоритм:

1. Собрать все движения по номенклатуре за период.

2. Отсортировать по дате.

3. Пройти по хронологии, при каждой отгрузке выбирая серию с наибольшим свободным остатком (FIFO).

4. Присвоить каждой строке ТЧ правильную серию с учётом всей цепочки.

Это — полноценный «сводный пересчёт по сериям». Сложно, но решает проблему полностью.

Вариант D: Не трогать — оставить бухгалтеру

Минуса -57 по AVK-346 / 01.02.26 — реальный дефицит. Возможно, был приход 01.02.26, который не оформили. Бухгалтер должен разобраться и оформить приход или списать.

Что в сухом остатке

Разбираю отчёт по одной номенклатуре без серий.

Что вижу

Общая картина по AVK-346:

Итого расход: 36 + 480 + 60 + 60 = 636. Остаток: 579 - 636 = -57.

Ключевая проблема

Последний документ КА-01010507 списал 60 единиц, когда на складе осталось только 3 (по общему остатку без серий).

Если смотреть по сериям (первый твой отчёт):

• 01.09.25 — 576 приход, израсходовано 576 (до 07.09.26) → 0.

• 01.02.26 — 3 приход, израсходовано 60 (в КА-01010507) → -57.

Что произошло фактически: все отгрузки реально шли из 01.09.25 (576 единиц на складе). Но в КА-01010507 оператор указал 01.02.26 — ошибка.

Правильно было бы КА-01010507 указать серию 01.09.25. Но к моменту этого документа (29.09.2026) серия 01.09.25 уже израсходована до нуля (последний расход по ней — 07.09.2026).

Парадокс:

• Фактически отгружали из 01.09.25.

• По бумагам 01.09.25 закончилась 07.09.2026.

• Отгрузка 29.09.2026 — 20 дней спустя — не могла быть из 01.09.25, если её уже не было на складе.

Значит, одно из двух:

1. Фактически 01.09.25 не закончилась — её остаток был больше 576, и мы видим ошибку в оприходовании.

2. Отгрузка 29.09.2026 шла из другой партии, которую не оприходовали вообще (нет прихода с нужной серией).

Почему обработка не исправила

На дату КА-01010507 (29.09.2026):

• 01.09.25 — остаток 0 (всё израсходовано 07.09.2026).

• 01.02.26 — остаток 3 (уже был использован).

• Третьей серии нет.

НайтиFIFOКандидата ищет серию с остатком >= 60 на дату документа. Такой серии нет → кандидат не найден → пропуск.

Логически обработка права: нельзя списать на серию, у которой остаток = 0 на дату отгрузки.

В чём корень проблемы

Причина минуса — не одна ошибка в КА-01010507, а цепочка из нескольких ошибок ранее:

• Если бы КА-00866504 (36) был списан не с 01.09.25, а с 01.02.26 — там было 3 (не хватило бы).

• Или если бы приход был оформлен правильно (579 вместо 576) — на 01.02.26 было бы 6, а не 3.

Реальная проблема: оприходование на склад дало 576 единиц одной серии, хотя фактически на склад пришло 579 единиц — разбитых на две партии: 576 + 3.

Приход был оформлен не полностью или с ошибкой. Минус 57 — следствие этого, а не ошибка операторов в расходных ордерах.

Что можно сделать в обработке

Вариант A: Расширить поиск кандидата

Смотреть не только на дату документа, но и в будущее/прошлое:

Идея: если на дату документа у серии остаток 0, но фактически серия приходила/расходовалась ранее — можно перераспределить расход по серии с наибольшим начальным остатком.

Алгоритм:

1. Собрать все серии по номенклатуре с любыми движениями за период.

2. Посчитать суммарный приход по каждой.

3. Найти серию, где приход > расхода (есть свободный «потенциал»).

4. Перенести часть расхода с минусовой серии на эту.

Проблема: у AVK-346 все серии исчерпаны (01.09.25 — 576/576, 01.02.26 — 3/60). Свободного потенциала нет. Значит, этот вариант не сработает.

Вариант B: Оставить бухгалтеру

Минус 57 — следствие недооприходования. Решение: найти акт приёмки 01.02.26 (или инвентаризацию), оформить приход на 57 единиц 01.02.26. Минус исчезнет.

Это — правильное решение, но вне зоны ответственности обработки.

Вариант C: Перераспределить расход по цепочке

Идея: с самого раннего документа проверить, какая серия была указана, и не было ли ошибки. Если все отгрузки фактически шли из 01.09.25 (576) — то КА-00866504 ошибочно списал 36 из 01.09.25, хотя реально 36 уже были из 01.02.26 (3 + 33 недооприходованных).

Это — сложная логика, требующая фактических данных о приёмке. Автоматически не решить

Что я предлагаю

1. Не пытаться исправить такие случаи автоматически

Минус 57 — это реальная недостача на складе (не пересорт, а реальная нехватка). Обработка корректно их пропускает — кандидата нет.

2. Добавить диагностику в обработку

Кнопка Статы или расширить Проверить — выводить список неисправимых минусов с пометкой "реальный дефицит":

text

=== НЕИСПРАВИМЫЕ МИНУСА (нет альтернативных серий) ===
  • AVK-346 / 01.02.26: -57
    Причина: реальная недостача (приход был меньше).
    Требуется: приход или инвентаризация.
  • ...

Это поможет бухгалтеру разобраться быстро.

ЗАКЛЮЧЕНИЕ

Обработка решает конкретную боль — пересорт по сериям — точечно и безопасно. Три режима, детектор записи, встроенный анализ динамики и промпт для ИИ делают её инструментом, а не просто скриптом.

Ключевое отличие от типовых решений: обработка не пытается перепровести всё подряд, а точечно устраняет причину — конкретный документ, который списал не ту серию.