В этой статье мы подробно разберем одну из часто встречающихся методологических и технических проблем при переходе на 1С:Управление нашей фирмой (УНФ) версии 3.0. Речь пойдет о ситуации, когда компании необходимо вести строгий партионный учет (для отслеживания сроков годности, ГТД или серий), но при этом процесс продаж требует гибкости в выборе конкретной партии для отгрузки.
Рассмотрим сценарий: клиент делает заказ, мы должны зарезервировать товар, чтобы его не забрали другие. Однако сделка может длиться долго (ожидание оплаты, самовывоз через месяц). За это время на склад может поступить новая партия, а нам, согласно правилам ФИФО (First In, First Out), выгоднее отгрузить по текущим "быстрым" сделкам старую партию, которая "висит" в резерве под "медленным" заказом.
В конфигурациях уровня 1С:Управление Торговлей (УТ) или 1С:ERP это решается разделением регистров свободного остатка и резервов или использованием ордерной схемы. В УНФ архитектура иная, что ставит специалистов в тупик. Давайте разберемся, как настроить систему правильно.
Прежде чем переходить к решениям, нам необходимо понять корень проблемы. Он кроется в структуре регистров накопления УНФ.
В отличие от "старших" конфигураций, в УНФ (в редакции 3.0 и выше) основной учет товаров, резервов и себестоимости ведется в едином регистре накопления — ЗапасыИЗатраты. Это упрощает систему, но накладывает жесткие ограничения (для проверки корректности данных можно использовать сравнение регистров "Запасы на складах" и "Запасы и затраты").
Если в настройках включен учет по партиям, то измерение Партия становится ключевым разрезом учета в этом регистре. Что это означает на практике?
ЗаказПокупателя и ставим товар в резерв, система делает запись в регистр:
РасходнуюНакладную на основании этого заказа, система будет пытаться списать именно ту партию, которая указана в резерве.В результате возникает "жесткая сцепка". Если мы зарезервировали под клиента "Партию №3", а через неделю хотим отдать ее другому клиенту (потому что она старая и портится), а первому отдать "Партию №4" (которая свежая), система нам этого не позволит без ручного вмешательства. Нам придется зайти в первый заказ, снять резерв, и только потом продавать.
Самый простой способ, который часто советуют на форумах, заключается в настройке политики заполнения реквизитов.
Суть метода: мы ведем партионный учет, но не заставляем менеджеров указывать партию на этапе приема заказа. Партия будет подбираться автоматически (по ФИФО) только в момент фактической отгрузки (в Расходной накладной).
Как это реализовать:
Партии номенклатуры установлена.Партия в документах было видимым, но не обязательным для заполнения в Заказах покупателя.Сценарий работы при такой настройке:
ЗаказПокупателя. Он указывает Номенклатуру и Количество. Поле Партия оставляет пустым.ЗапасыИЗатраты падает запись о резерве, где измерение Партия имеет значение ПустаяСсылка (или специальное служебное значение пустой партии).РасходнуюНакладную, система может попытаться списать товар также с пустой партии. Но на складе товар лежит (пришел от поставщика) с заполненной партией (например, "Партия от 01.01.2024").Возникает так называемая "пересортица по аналитике". В резерве числится товар "без партии", а на остатке лежит товар "с партией". Стандартный контроль остатков может не дать провести отгрузку, либо потребует выполнения операции корректировки или автоматического распределения.
В УНФ есть механизмы автоматического подчета остатков, но этот метод считается "рискованным", если вы хотите видеть точную себестоимость в моменте. Он подходит, если вам не важно, какая именно партия зарезервирована, а важно только общее количество.
Более правильным с точки зрения методологии УНФ является подход, разделяющий "обещание товара клиенту" и "жесткий резерв". Для этого мы будем использовать статусы документа ЗаказПокупателя.
Идея заключается в следующем: пока заказ находится в долгой воронке продаж (ждет оплаты, согласования), мы не делаем движений по регистру ЗапасыИЗатраты в колонке "Резерв". Или делаем, но без привязки к партии.
Настройка схемы:
Алгоритм действий менеджера:
Таким образом, мы добиваемся эффекта "скользящего" ФИФО: старые партии уходят тем, кто готов забрать товар первым, независимо от того, кто первый сделал заказ.
Если вам необходимо именно "застолбить" товар (чтобы его не продали другому), но при этом иметь возможность гибко управлять партиями, в УНФ существует специализированный документ — РезервированиеЗапасов.
Этот подход требует большей ручной работы, но дает полный контроль.
Как это работает:
ЗаказеПокупателя мы не ставим автоматический резерв (в статусе заказа выбрано "не резервировать").РезервированиеЗапасов.Если товары отсортированы по времени поступления, система подставит в резерв наиболее старую партию. Если ситуация меняется (нужно отдать эту партию другому), мы:
РезервированиеЗапасов с видом операции "Снятие резерва" (или корректировка) для старого заказа. Освобождаем "Партию 3".Это трудоемко, если делать вручную постоянно, но это штатный механизм, который не приводит к ошибкам в данных.
Если объем заказов велик, и менеджеры не могут вручную перекидывать резервы или следить за статусами, целесообразно прибегнуть к помощи программиста 1С для создания небольшого расширения конфигурации.
Поскольку штатный функционал УНФ 3.0 с жестким партионным учетом не позволяет реализовать логику "мягкого резерва" одной галочкой, можно внедрить алгоритм автоматической подмены партии при проведении РасходнойНакладной.
Логика работы расширения:
При попытке провести расходную накладную, если возникает ошибка нехватки свободной партии (потому что она в резерве под этим же заказом, но с другим ID партии), алгоритм должен:
// Псевдокод алгоритма
Функция ПередЗаписьюРасходнойНакладной(Отказ, РежимЗаписи, РежимПроведения)
// 1. Определить потребности документа (что хотим продать)
Для Каждого Строка Из ТЧ_Запасы Цикл
// 2. Проверить, есть ли свободный остаток на складе по ФИФО
// Игнорируя партию, указанную в строке, ищем самую старую на складе
СтараяПартия = НайтиСамуюСтаруюПартию(Строка.Номенклатура);
Если СтараяПартия <> Строка.Партия Тогда
// 3. Если в заказе зарезервирована "НоваяПартия", а мы хотим списать "СтаруюПартию"
// Нужно выполнить "тихую" замену резерва
ВыполнитьПеребросРезерва(Заказ, НоваяПартия, СтараяПартия);
// 4. Подменить партию в самой накладной
Строка.Партия = СтараяПартия;
КонецЕсли;
КонецЦикла;
КонецФункции;
Такой подход автоматизирует процесс, описанный в "Решении 3". Система сама "на лету" понимает: "Ага, пользователь хочет отгрузить товар. Под этот заказ зарезервирована Партия 5. Но на складе пылится Партия 3. Я сейчас молча сниму резерв с Партии 5, переставлю его на Партию 3 и сразу спишу её".
Проблема резервирования в УНФ 3.0 при использовании партий связана с тем, что система хранит резерв в разрезе конкретных партий. Чтобы реализовать продажу по ФИФО при длительном цикле сделки, используйте один из методов:
Наиболее сбалансированным решением для большинства компаний является комбинация Решения 2 (грамотное использование статусов) и, при необходимости, Решения 3 (ручная корректировка для исключительных ситуаций).